Medium-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.

Target Profile: Internal-facing, complex workflow logic with up to 1 level of approval, 2-5 API integrations, customized UX/UI. This requires a more formalized team and basic governance structures.

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 High-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		Part time resource
Project Manager		Full time resource
Developer		Multiple full time resources
Solution Architect		Part time resource
Environment Admin		Part time resource
Quality Assurance		Full time resource

1. Project Overview

Question	Answer	Medium-Complexity Check/Details
Application Name
Current Process to be Replaced		Digitization of approval process, middleware
Primary Goal of Application		The "Why" - must be a single, concise statement
Estimated Application Modules		5-10 Modules (Major screens, tabs, or user journeys)
Target User Count		Medium volume (e.g., 50-500 internal users)
Number of distinct User Personas		2-5 Personas (e.g., Submitter, Approver, Admin, Reviewer)
Is this application internal or external facing?		Must be Internal Facing Only
Is this application a dependency for any other application or system?		Should be No. Introducing dependencies introduces complex architectural considerations the team has not experienced yet.

2. Business Functionality & Workflow

Question	Answer/Detail	Medium-Complexity Check/Details
How many distinct steps are in the workflow?		5-10 steps (Increased complexity)
How many approval levels are required?		1-2 levels (Must be defined based on role)
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?		Medium complexity rules (Logic must be well-documented)
If approval/rejections workflows are required, how are users to be notified?
To what extent do user actions and approvals need to be audited?		Can be included if simple
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?		Some data transformation (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)?		Can be Yes, but consult with SA about complexity

3. Technical Scope & Data

Question	Answer/Detail	Medium-Complexity Check/Details
How many external systems must be integrated?		2-5 API integrations (e.g., Salesforce, Legacy CRM, Core Banking System). Should not be highly complex integrations
Are the services the application relies on available today or will they need to be built?		Available today
Is data transformation required?		Yes (e.g., mapping fields, simple data restructuring)
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?		Can increase application complexity if complicated
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	Medium-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?		Should be No
Are there specific accessibility (e.g., WCAG) requirements?		Must be No (Focus on standard compliance)

5. Security & Access Control (RBAC)

Question	Answer/Detail	Medium-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?		Simple hierarchies are acceptable (e.g., Approver > Manager > Director)
Does a user's Group/Role restrict the data they can see?		If yes, it's helpful to have this conversation separately for each module once the schema and UI are more developed. (Data visibility restrictions should be mandatory. E.g., Regional sales manager only sees their region's data)
Are there granular permission requirements per field/component?		Yes (Expected for data-heavy apps)
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

Question	Answer/Detail	Medium-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?		Basic monitoring (SLA, Uptime) required (e.g., Specific metrics or dashboards needed)
Which artifacts are required from your delivery team? (e.g., Technical Design, Data Dictionary)?		Standardized documentation (Runbook, TDD required)
Is a formal disaster recovery (DR) plan required for this application?		Should be No
Does the application require an immutable audit trail of all transactions and data changes?		Required for most financial/insurance compliance, but can increase complexity