01/
Users and roles
Identify who uses the system, what each role can see or change, which decisions need approval, and where responsibilities cross between teams or organisations.
Custom Software Development
Custom software development for requirements that standard tools do not fit.
Start with the decision
Make the custom part
earn its place.
Custom software is not automatically the best answer. We first compare the requirement with what an existing product, configuration, integration, or extension can responsibly support.
TIER01
Use an existing product
TIER02
Configure an existing product
TIER03
Integrate or extend
TIER04
Build the custom core
Requirement and system context
Start with the work
the software has to support.
A feature list rarely explains the whole system. Before detailed scope, design, or architecture, establish the people involved, the work they perform, the information they depend on, and the conditions that change what should happen next.
02/
Workflow and exceptions
Map the normal path and the cases that break it: incomplete information, rejected requests, duplicate records, unavailable dependencies, manual review, escalation, and recovery.
03/
Information and source of truth
Clarify which data the system creates, which data comes from elsewhere, where authoritative records live, and who is responsible for corrections or conflicts.
04/
Existing systems and integrations
Understand the products, APIs, files, devices, or manual processes the new software must connect to, including authentication, ownership, timing, failure behavior, and recovery.
05/
Constraints and consequences
Record known regulatory, privacy, security, accessibility, platform, operational, time, and budget constraints with the people authorised to interpret them.
06/
Evidence of usefulness
Define how the team will recognise that the release supports the intended workflow: an observable task completion, a replaced manual step, a functioning connection, or another agreed condition.
Scope and system boundary
Define the system boundary
before expanding the feature list.
A useful first scope should support a real workflow from beginning to end while making external dependencies, operational responsibility, and later decisions visible.
(001)
Identify the custom core
Name the behavior that makes the system specific to the requirement. This is where custom work should create the most value and where generic components are least likely to fit.
(002)
Reuse standard components deliberately
Authentication, payments, messaging, storage, analytics, search, and other common capabilities may use established products or services when their limits, cost, data behavior, and operating implications are acceptable.
(003)
Choose the required surfaces
Decide whether the first release needs customer, operational, administrative, web, or mobile surfaces. A surface should exist because a user and workflow require it.
(004)
Establish system connections
Define which existing systems remain authoritative, what data crosses each boundary, how often it moves, and what users see when an integration is delayed or unavailable.
(005)
Keep later decisions visible
Record deferred capabilities, the assumptions behind them, and the conditions that would cause the team to revisit them.
Technology decisions
Engineering stack
& foundations
The stack follows the requirement, not the other way round. These are the categories this engagement typically has to decide.
01
TypeScript & Node.js
02
Go & Python
03
PostgreSQL & Redis
04
Next.js & React
05
Docker & Kubernetes
06
GraphQL & REST APIs
Possible scope
Connect the product decisions
to the software delivered.
The exact responsibility depends on the starting state and agreed scope. A custom software engagement may connect several of these areas; none should be assumed automatically.
User and role definitionWorkflow and exception mappingRequirement and constraint reviewPrioritised scope and acceptance conditionsSystem-boundary and dependency decisions
Information structure and product flowsInterface states, permissions, validation, and errorsPrototypes for decisions that need testing or alignmentRepeated interface patterns where justifiedDesign handoff that accounts for implementation behavior
Frontend and backend behavior for the agreed systemData models and access rulesAdministrative and operational interfacesAPIs and internal system boundariesTechnical decisions proportionate to current requirements
External system and API connectionsAuthentication and access boundariesMapping, validation, reconciliation, and error handlingScheduled, event-driven, or user-triggered exchangeVisibility when dependencies fail or data needs review
Acceptance scenarios for the agreed workflowReview of important roles, states, and exceptionsEnvironment and release responsibilitiesDefect and decision handling before releaseEvidence appropriate to the agreed quality and risk needs
Repository, environment, account, and asset access as agreedDecision, setup, or operating documentation in scopeHandoff expectations for the people who operate or continue the softwareAn explicit choice between handoff, a later phase, or ongoing product engineering
Architecture decisions
Make trade-offs explicit
before they become architecture.
Architecture should reflect real product and operating conditions. The useful decision is the one whose reason and consequence are understood.
01
Standard capability or custom behavior?
Use established products where the capability is common and their limits are acceptable. Build where the behavior defines the product or operating model.
02
One application or several connected surfaces?
One application can reduce coordination. Separate surfaces may better serve distinct users, devices, permissions, or operating contexts.
03
One deployment or distributed services?
Separate components only when team boundaries, scaling characteristics, reliability needs, integration constraints, or release independence justify the added coordination.
04
Synchronous or delayed connection?
Immediate responses may matter for user decisions. Queued or scheduled exchange may better handle dependency failure, throughput, or reconciliation.
05
Strict workflow or flexible operation?
Strong rules can improve consistency. Operational overrides may be necessary for genuine exceptions; the system should define who can override and what is recorded.
06
Build for now or anticipated change?
Support credible next steps without designing every imagined future. Record assumptions and revisit them when product evidence changes.
07
Handoff or continuation?
Plan who will operate, maintain, and change the system after the agreed release. Access, documentation, and decision history differ between these paths.
Inspectable outputs
Define the outputs another team
can inspect and use.
Deliverables should make the path from requirement to software visible. The exact set is agreed for the engagement; every project does not include every item.
01/
Requirement and workflow record
Users, roles, workflows, exceptions, constraints, external systems, priorities, and acceptance conditions relevant to the scope.
02/
Prioritised product scope
A clear first release or work package, including what is included, what remains later, and which assumptions affect the boundary.
03/
Product flows and interface decisions
States, actions, permissions, validation, errors, and repeated patterns required for users to complete the agreed workflow.
04/
Architecture and integration decisions
System boundary, data responsibilities, key interfaces, dependency behavior, environment assumptions, and material trade-offs.
05/
Working software
Implemented product behavior and connected surfaces included in the accepted scope, demonstrated against agreed scenarios.
06/
QA and release evidence
Agreed checks, known limitations, acceptance results, release responsibilities, and unresolved decisions appropriate to the scope and risk.
07/
Access, documentation, and transition
Repositories, assets, environments, setup or operating information, and handoff or continuation actions agreed commercially and legally.
Delivery and engagement
Match the starting engagement
to what is already known.
The first engagement should reduce the uncertainty that matters and produce work another person can inspect.
01
BOUNDED DISCOVERY
Focused definition
Use a bounded definition stage when users and the problem are understood but workflows, dependencies, system boundaries, or first-release priorities need decisions before build scope can be agreed.
02
FIXED-SCOPE MILESTONE
Defined product build
Use a project-shaped engagement when the workflow and acceptance boundary can be made sufficiently clear. State product, design, engineering, integration, QA, and release responsibilities for the actual scope.
03
STAGED RELEASES
Staged delivery
Use staged work when the system has several dependencies or when one complete workflow can be released and evaluated before expanding into later areas.
04
CONTINUOUS CADENCE
Ongoing product engineering
Use an ongoing model when the product has an active roadmap and continued responsibility is genuinely required beyond one release. This is a separate commercial decision.
Fit and routing
Use the service
that owns the defining condition.
Custom Software Development is the right starting point when a requirement-specific system or connected workflow defines the work. A narrower service may be more useful when one condition dominates.
01/ ALTERNATIVE
SaaS Product Development
Choose this when the multi-customer product model, account separation, roles, subscription, configuration, or continuing SaaS operations define the requirement.
02/ ALTERNATIVE
Web or Mobile Application Development
Choose the surface-specific service when browser delivery or iOS/Android and device context define the work more than the broader bespoke system.
03/ ALTERNATIVE
MVP Development
Choose this when the primary decision is how to scope and engineer the first useful release of a validated requirement.
04/ ALTERNATIVE
Product Modernisation & Improvement
Choose this when an existing product needs coordinated change across functionality, UX, code, architecture, integrations, or infrastructure.
05/ ALTERNATIVE
Ongoing Product Engineering
Choose this when the primary need is continued roadmap delivery and responsibility beyond one bounded release.
06/ ALTERNATIVE
AI-Enabled Software & Automation
Choose this when a defined information task, assisted workflow, or bounded agent behavior is the principal change requiring evaluation and fallback design.
Frequently Asked Questions
Custom Software Development questions,
answered clearly.
Technical delivery and architecture details. Key decisions regarding code quality, integrations, and handoff rituals.
Custom work may be justified when the defining workflow, roles, rules, integrations, or product behavior cannot be supported adequately through an existing product or reasonable configuration. The comparison should include implementation effort, operating change, data and integration limits, ongoing costs, and responsibility for the system.