Low-Complexity Application Considerations

Use this comprehensive considerations checklist to interview stakeholders, conduct due diligence, and assist in scoping your Unqork applications. As you complete this document, pay close attention to the complexity check as this will help determine resource requirements and may provide an opportunity to dive deeper, reevaluate in scope requirements, or change the expected complexity of the application. This does not apply to all rows, but we’ve added context for critical requirements that can significantly impact complexity. Target Profile: Internal-facing, single-party workflow, 1-2 simple integrations, no multi-language support, simple UX/UI.

If your application does not fit this profile, or at any point you exceed the complexity check for this type of application, we recommend either revisiting scope or reclassifying the application complexity and heading to the Medium-Complexity Application Considerations article.

Additionally, please note that this is not an exhaustive list. There may be additional considerations you need to make, teams you need to speak with, or areas that require additional due diligence. For questions that do not apply to your application, please feel free to skip after you've had a discussion with your team.

Project Team

Use the following table to list out all team members who will be involved in the development of this application. The recommendations in this section are not requirements, but should be used as guidelines when assigning team members to this project.

Role	Name	Recommendation
Technical Champion		Full time resource
Business Champion		Partial resource
Project Manager		Partial resource
Developer		Full time resource
Solution Architect		Partial resource
Environment Admin		Partial resource
Quality Assurance		Partial resource

1. Project Overview

Question	Answer/Detail	Low-Complexity Check/Details
Application Name
Current Process to be Replaced		Spreadsheet digitization, Basic form simplification
Primary Goal of Application		The "Why" - must be a single, concise statement
Estimated Application Modules		Max 3-5 Modules (How many major screens/tabs will the user navigate?)
Target User Count		Low volume (e.g., under 50 internal users)
Number of distinct User Personas		2-3 Personas (e.g., Submitter, Manager, Admin)
Is this application internal or external facing?		Must be Internal Facing Only
Is this application a dependency for any other application or system?		Must be No

2. Business Functionality & Workflow

Question	Answer/Detail	Low-Complexity Check/Details
How many distinct steps are in the workflow?		Must be simple (Max 4-5 steps)
How many approval levels are required?		Max 1-2 levels
Will the application require conditional logic?		Keep logic simple for this type of application (e.g., Show/Hide fields based on user input)
Is multi-language support required?		Must be No (Keep it simple for this phase)
Will the application require complex conditional logic?		Yes (Non-linear logic expected. E.g., Dynamic field visibility based on multiple conditions)
Are there any required decision-making rules?		Must be rule-based (No advanced modeling)
If approval/rejections workflows are required, how are users to be notified?
To what extent do user actions and approvals need to be audited?		Should be simple and straightforward
Do submissions/tasks need to be categorized by status? If so, what are the statuses?		Make sure to account for edge cases
Are there document generation requirements?		Keep document generation minimal/standard (e.g., PDF/Excel generation)
Is there any process logic that must be decoupled or run externally (e.g., microservice call)?		Needs to be No
Is transactional integrity required (i.e., the entire process must succeed or fail automatically)?		Needs to be No

3. Technical Scope & Data (Integrations)

Question	Answer/Detail	Low-Complexity Check/Details
How many external systems must be integrated?		Max 1-2 external simple API integrations (e.g., Salesforce, Legacy CRM, Active Directory)
Are the services the application relies on available today or will they need to be built?		Available today
Is data transformation required?		Keep transformation minimal or non-existent (e.g., Must reformat system A's response for display)
What is the submission volume (per day)?		Medium volume (e.g., 100-500 per day)
Should incomplete submissions be retained?		If yes, list timeframe and detail situation
Can users return to an incomplete submission?
Are there API timeout considerations or general limitations that need to be accounted for?		Make sure you set realistic timeouts, align timeouts across application layers
What validation is needed for APIs?		Need agreement across business on API requirements(e.g., payload, data type, format, fields, etc.). optimize usage, and use asynchronous processing
What error handling and mitigation must be in place for APIs?
Do API responses need to be filtered or sorted for downstream processes?		It's important to think through how data is returned and how it will be used throughout the application.
Are there any batch file processing requirements?		Must be No (e.g., Importing large spreadsheets daily)
Is sensitive data (e.g., PII) being stored/processed?		Must align with standard encryption methods
What is the data retention policy?		(e.g., Must keep records for 7 years)
Are there any required asynchronous jobs?		Can be yes if simple (e.g., Scheduled data cleanup, delayed notifications)
Are there data storage concerns across regions?		Should be No to keep complexity down
Will any data be stored in Unqork? Are there any requirements to not store data in Unqork?
How often (if ever) should submissions be cleared to maintain performance?
What is the error handling and retry strategy for failing external API calls (timeouts, circuit breakers)?		Must define specific resilience patterns.
What are your data export needs?		What data needs to be sent where, and how often?

4. UX/UI and Environment

Question	Answer/Detail	Low-Complexity Check/Details
How will users access the application? What does the launch of this software look like?		(E.g. intranet, consumer portal)?
Are there any custom domain or SSL certificate requirements?		Must be No for initial scope
Are there specific accessibility (e.g., WCAG) requirements?		Must be No (Focus on standard compliance)

5. Security & Access Control (RBAC)

Question	Answer/Detail	Low-Complexity Check/Details
What compliance standards apply?		WORM, COOL, HIPAA, CCPA, GDPR
How will users be authenticated (e.g., SSO, OIDC)?		Standard SSO/Authentication is preferred (e.g., identity provider, existing system)
Is a user deprecation process needed? What happens to in progress or assigned work if initiated?
How are new users added to the system? How are user details updated (if necessary)?
Are there complex role hierarchies within the app?		Max 1-2 hierarchy levels (e.g., Approver > Manager)
Does a user's Group/Role restrict the data they can see?		Must be simple (e.g., Regional sales manager only sees their region's data). If yes, it's helpful to have this conversation separately for each module once the schema and UI are more developed.
Are there granular permission requirements per field/component?
How is PII/PHI/CII data handled, encrypted, and masked within the application?		Should be No
What is the mandatory frequency for vulnerability/penetration testing (e.g., quarterly, pre-release)?		Must adhere to enterprise security calendar.
Will users from one application use the same level of permissions in another application?

6. Governance & Lifecycle (Audit & Support)

Question	Answer/Detail	Low-Complexity Check/Details
What is the expected peak concurrent user load?
What are the required load testing/performance test scenarios and success benchmarks?
Are there platform monitoring requirements?		Should be simple, standard monitoring (e.g., Specific metrics or dashboards needed)
Which artifacts are required from your delivery team? (e.g., Technical Design, Data Dictionary)?		Must be minimal (aligned with initial project)
Is a formal disaster recovery (DR) plan required for this application?		No
Does the application require an immutable audit trail of all transactions and data changes?		Should be No as it increases complexity