When a custom build makes sense
A custom product is useful when the workflow is central to your business, users need something existing tools cannot provide, or the software itself is the product. Examples include customer portals, internal operations platforms, marketplaces and B2B SaaS products.
When a CRM extension or an existing tool can handle the job, that may be the better first step. Discovery should resolve this choice before a large build is approved.
Define a useful first release
- Identify the primary user and one complete workflow, including the unhappy path.
- Agree which roles, screens, records and integrations are required for that workflow.
- Design the experience and data model together so the interface reflects operational reality.
- Build and test the application, permissions and external-system boundaries.
- Prepare deployment, acceptance review, documentation and handover for the agreed release.
Milestones with visible decisions
| Stage | What you review |
|---|---|
| Discovery | User problem, existing-tool options, scope, risks, dependencies and acceptance criteria. |
| Design | The end-to-end journey, important states and how people recover from mistakes. |
| Engineering | Working increments with real integration assumptions tested early. |
| Release | Acceptance results, deployment plan, operational ownership and known limits. |
| Handover | Repository and account access, setup notes, runbook and agreed support coverage. |
Scope first, then a proposal
User roles, integrations, migration, permissions, content readiness, mobile requirements and operational constraints shape the cost and schedule. We quote after these are understood and identify assumptions that could change the estimate.
The proposal separates discovery, the first release and later phases. It names exclusions such as third-party subscriptions, provider usage, additional platforms, unplanned migration and new features. Delivery windows depend on the agreed scope and timely access, content and decisions from your team.
Build packages include three consolidated design revision rounds within the agreed scope. New directions or functionality are estimated separately. Defects against the approved scope do not consume a revision round.
Build for the team that will run it
We agree on intellectual property, source-code access, infrastructure accounts and deployment responsibilities before implementation. Handover should let the receiving team understand how to run, change and support the release.
Our LuckyTruck work spans CRM integrations, document workflows and AWS delivery. EasyInsurance shows experience delivering a marketplace across several product lines. These are examples of the types of systems we have worked on, not a promise to reproduce their entire scope inside an MVP.
Care after launch
Support and managed hosting are scoped to the application. The proposal confirms monitoring, updates, backups where applicable, infrastructure allowance and response expectations. Rubix-managed hosting requires an active care plan.
New features, third-party overages and work outside the agreed service coverage are scoped separately. A client’s internal team can also take over; we plan access and documentation around the chosen operating model.
Working across time zones
We work remotely with teams in the UK, Europe, the US and Australia. Delivery is in English; working-hour overlap, review cadence, billing currency and any data-location requirements are agreed in the proposal.
Useful before the first call
- MVP scope and handover checklist →
- Custom build or extend existing tools? →
- EasyInsurance case study →
