Custom Build covers SaaS products, portals, dashboards, internal tools, API services and specialised digital systems. The route begins with decisions: who uses it, what they need to accomplish, what data moves and which risks must be proven first.
Example direction: a focused SaaS release joining acquisition, product workflow, billing and usage.
Investment signal
Discovery led
Pricing route
Tailored scope
02Choose by need
Start with the business situation, then shape the scope.
Custom work is estimated from product scope, user roles, workflow depth, data model, integrations, quality requirements and release strategy. We normally separate discovery, build phases and ongoing support so you can make one investment decision at a time.
This route usually fits
Founders validating a focused SaaS or product concept
Teams replacing spreadsheets with an internal platform
Businesses needing customer or partner portals
Organisations commissioning dashboards, APIs or specialised tools
The work should create
01A product architecture grounded in real user tasks
02A prioritised first release instead of an oversized feature list
03Reviewable development phases with acceptance criteria
04Documented ownership, deployment and support decisions
03Working scope
What a custom build can include.
These are scope ingredients, not a locked bundle. Your quote keeps the useful parts, removes the unnecessary ones and identifies anything that needs a separate phase.
01
Product definition
Translate the idea into users, jobs, states and decisions the product must support.
Stakeholder and user goals
Feature and workflow map
MVP boundary
Risk and assumption register
Delivery roadmap
02
Experience and engineering
Design the interface and technical system as one product.
UX flows and interface system
Frontend and backend development
Data model and permissions
API and third-party integrations
Responsive or mobile experience
03
Release and operation
Prepare the product for real use, feedback and continued ownership.
Testing and acceptance criteria
Deployment configuration
Monitoring and error visibility
Technical documentation
Handover or support agreement
System exampleData-intensive tools require clear signal hierarchy, latency expectations and failure states.
Experience detailCustom dashboards are scoped around decisions, data sources and user roles.
04How you can engage us
One-time build, monthly support or a phased route.
The commercial model follows the work. You do not have to accept a monthly agreement to commission a build, and ongoing work is defined with its own responsibilities and allowance.
Third-party subscriptions, hosting usage and advertising spend are identified separately from our professional fees.
First decision
Product discovery
A bounded engagement that turns an idea into a testable scope, architecture and release plan.
User and workflow definition
MVP prioritisation
Technical risk review
Phased build estimate
Build route
Phased implementation
Design and engineering progress through agreed releases, each with demonstrable outcomes.
Milestone-based delivery
Reviewable product increments
Acceptance criteria
Release documentation
After release
Product support retainer
An optional monthly capacity agreement for maintenance, incidents and planned improvements.
Priority engineering support
Dependency and security maintenance
Monitoring and issue resolution
Agreed improvement capacity
05Customise the route
Add capability where it changes the result.
Optional work is included because it supports the business case, not because a package needs more features.
A
Product capabilities
Add the features that create the product's operating model.
Subscriptions and billing
Role-based workspaces
Notifications and messaging
Admin and moderation tools
B
Data and intelligence
Extend how the product collects, analyses or acts on data.
Custom APIs
Real-time data
AI-assisted workflows
Analytics and reporting
06Delivery route
Each investment decision produces something reviewable.
Timing is confirmed after scope and content responsibilities are clear. Accelerated delivery changes coordination and cost, never the quality standard.
01
Discover
Define users, outcomes, constraints, risks and the smallest useful first release.
02
Prototype
Resolve key journeys and technical assumptions before full production investment.
03
Build
Deliver in demonstrable increments with testing and stakeholder acceptance.
04
Release
Deploy, monitor, document and choose the ongoing product ownership model.
What we need from you
Good inputs keep the project moving.
The business problem and intended users
Current process, data sources and known constraints
A product owner who can make scope decisions
Security, privacy, performance and launch expectations
Quoted separately when needed
Boundaries stay visible.
Third-party licences and infrastructure usage
Unbounded feature changes during a fixed phase
Regulatory or security certification
Data acquisition rights
Guaranteed commercial or investment performance
07Before you choose
Questions about this pricing route.
The quote is the final source of truth for scope, cost, timing and responsibilities.
01Can you give a fixed price before discovery?
We can usually give a broad planning range, but a dependable build quote requires enough detail about users, workflows, data and integrations. Discovery creates that detail.
02Do we need to build the whole product at once?
No. A phased route is normally safer. We identify the smallest release that can prove value, then plan later capabilities around evidence and priority.
03Can our internal team take over?
Yes. Handover can include documentation, environment access and technical walkthroughs. We can also remain available through a support retainer if shared ownership is more practical.
Turn this starting point into your itemised quote.
Tell us the business problem, budget range and preferred timing. We will separate the essential build, optional upgrades and any sensible later phases.
