Solution
Custom business platform
A platform built around how your business actually runs — customer portal, internal tooling, database and the automation between them.
This is the engagement for businesses whose operating process is genuinely their advantage and who have run out of road configuring products that were designed for someone else. It is expensive to build and permanent to own, and the first thing we do is try to talk you out of it.
Where it is justified — because licensing at your headcount exceeds build cost, or because the workflow is unusual enough that configuration means permanent friction — the result is software shaped like your business rather than a business bent to fit a product.
Why this is sold as one engagement
Build-versus-buy has moved decisively against building anything generic. CRM, support, project management and analytics are covered well enough by products that recreating them is difficult to justify. What has not been commoditised is the specific operational workflow a business runs on.
The reason to build the portal, the internal tooling and the automation together rather than separately is that they share a data model. Built as three projects they acquire three models that disagree, and reconciling them later costs more than building them together would have.
The real expense is not the initial build. It is the five years afterwards — dependencies, security patches, the person who understood it leaving — and a quoted build price that ignores that is quoting for a third of the commitment.
What is included
- Build-versus-buy assessment
- An honest view on whether this should be built at all, delivered before you commit budget.
- Domain model and schema
- Entities, relationships and lifecycle states designed for evolution rather than for launch.
- Customer portal
- Authenticated access to documents, data and actions, with role-based permissions.
- Internal dashboard and admin
- Operational tooling for the team, with audit logging and real permission boundaries.
- Database and API
- PostgreSQL with a documented, versioned REST API and a migration strategy.
- Integrations
- Connections to the CRM, accounting, payment and other systems already in use.
- Workflow automation
- The manual steps between systems removed, with error handling and alerting.
- Authentication and roles
- Sessions, single sign-on and permissions built to current standards rather than invented.
- Monitoring and tests
- Structured logging, error tracking and automated coverage on the flows that are expensive to break.
- Documentation and handover
- Architecture notes, runbooks and repository access, so another team could take it over.
How it runs
Challenge the requirement
We start by trying to talk you out of it. If a configured product plus integration covers most of the requirement, that is the better commercial decision and we will say so before quoting a build — including when that costs us the project.
Model the domain
Entities, relationships and lifecycle states agreed before any interface work. This decision has the longest consequences of anything in the project and it is the one most often rushed under delivery pressure.
Build a thin slice end to end
One complete path through the system, deployed, before any breadth. It surfaces the integration and architecture problems while they are still cheap to fix.
Widen
Additional flows built against a proven foundation, with instrumentation from the first deploy rather than added after the first incident.
Integrate
Connections to existing systems with idempotent processing, reconciliation and failure alerting, because the space between vendors is where nobody takes responsibility.
Document and hand over
Architecture notes, runbooks, repository and infrastructure access. You should be able to appoint another supplier without a rewrite.
What changes
- Software shaped like your process
- Rather than a process bent to fit a product’s assumptions.
- One data model
- Portal, internal tooling and automation share it, so they do not disagree.
- Customers self-serve
- A portal removes the phone calls and emails that ask what a system already knows.
- Predictable change cost
- A model designed for evolution, so year two of features does not cost more than year one.
- Observable in production
- Logging, error tracking and monitoring from day one rather than after an incident.
- No supplier lock-in
- Conventional technology, your repository, documentation good enough to hand to someone else.
Who this is for — and who it is not
A good fit if
- Your operation runs on a spreadsheet nobody dares restructure.
- Per-seat licensing has become your largest software cost.
- You are fighting a product’s assumptions on every workflow.
- Customers phone to ask things a system already knows.
- The process that makes you money has no software behind it.
Not a good fit if
- A product plus integration would cover most of the requirement — which is the usual answer.
- You need it live in six weeks; that is a prototype, not a platform.
- Nobody internally can own the system after handover.
- The budget covers the build and not the years of maintenance that follow.
On price. Scoped in a paid discovery phase and quoted per delivery phase. Any figure quoted before a domain model exists is fiction, and we will tell you the realistic annual maintenance cost at the outset rather than presenting the build price as the total.
What we need from you
Custom platforms succeed or fail on domain knowledge and ownership rather than on engineering.
- Someone who knows the process deeply
- Available regularly, not for a single workshop. The domain model is only as good as the understanding behind it.
- Authority to simplify
- Encoding a convoluted process makes it permanent. Someone needs the standing to decide a step can be removed.
- A future system owner
- Named at the start, not at handover. A platform nobody owns internally degrades regardless of how well it was built.
- Realistic maintenance budget
- The build is a fraction of the lifetime cost. Planning only for delivery guarantees an unmaintained system in year three.
- Access to systems it must integrate with
- Including credentials and, where relevant, vendor cooperation. Integration access is a frequent early blocker.
- Patience for the thin slice
- One narrow path delivered end to end looks like slow progress and is what makes the rest predictable.
Where this gets difficult
The hardest judgement is whether to build at all, and the honest answer is usually no. We would rather lose the project than build something a configured product would have covered, because the client discovers that themselves eventually and remembers who told them.
The second is data model discipline. Decisions made in the first fortnight determine what is cheap and expensive to change for the life of the system, and delivery pressure pushes teams to rush exactly the decision that should be slow.
The third is scope discipline in the portal. Customer portals attract feature requests indefinitely, and a portal that does three things well beats one that does eleven things adequately — particularly since every feature is maintenance forever.
A fourth is the integration surface. A platform that connects to five systems inherits five vendors’ API change schedules, and someone has to own the space between them. That ownership needs naming rather than assuming.
A fifth is testing proportion. Full coverage is rarely worth it; zero coverage on authentication, payments and permissions is negligent. Deciding where the line sits is a judgement we make explicitly rather than by default.
Sixth, handover reality. A system only one supplier understands is a commercial hostage, and documentation quality is the difference between a platform you own and a dependency you rent.
Finally, maintenance honesty. A build price that ignores five years of dependencies, patches and platform changes is quoting a third of the commitment, and we would rather set that expectation before you sign than after.
A further difficulty is the pull toward rebuilding adjacent systems. Once a platform exists, every neighbouring process looks like it should be inside it, and scope grows in ways that individually seem reasonable and collectively produce something that took twice as long and does several things adequately.
The second is that the client's understanding of their own process improves during the build, which is genuinely valuable and also a source of change. Phasing exists partly to give that learning somewhere to land without destabilising work already underway.
Finally, the handover is the part most often under-funded. Documentation and training are the difference between a platform you own and a supplier you cannot leave, and they are the first items cut when a project runs tight.
The services this combines
Custom Software & Platforms
Building the system when nothing off the shelf fits — and telling you honestly when something off the shelf does.
Read more →Systems Integration
Making the systems you already pay for talk to each other, reliably, without a person in the middle re-typing things.
Read more →Data Engineering & BI
Getting numbers out of the systems that hold them, into one place, in a state somebody can actually make a decision from.
Read more →Cloud, DevOps & Infrastructure
The layer everything else runs on — deployed reproducibly, monitored properly, backed up in a way that has actually been tested.
Read more →Business Process Automation
Removing the manual steps between systems — the copying, re-typing, chasing and exporting that consumes hours nobody counts.
Read more →Maintenance & Ongoing Support
Keeping what has been built working — patched, monitored, backed up and quietly improved, with a response window written into a contract.
Read more →Questions
Should we build or buy?
Buy, unless the process is genuinely your advantage, licensing at your headcount exceeds build cost, or the workflow is unusual enough that configuration means permanent friction. We give you our view before you commit, including when it costs us the project.
What does it cost?
It varies by an order of magnitude with scope, so a figure quoted before a domain model exists is fiction. We scope in a paid discovery phase and quote per delivery phase afterwards.
How long does it take?
A useful first version of a focused platform is typically three to five months. Anything promising a complete platform in six weeks is describing a prototype.
Who owns the code?
You do, in your repository, with no licensing restrictions from us. We use conventional technology specifically so another team can take it over.
What about maintenance?
It is real and continuous — dependencies, security patches, platform changes. We offer it as a retainer and we will tell you the realistic annual cost at the outset rather than presenting the build price as the total.
Can you take over an existing system?
Often. We start with an assessment of structure, test coverage, dependency currency and security posture, and we will tell you honestly whether a rewrite is genuinely cheaper — a conclusion we reach less often than it is reached for us.
Why build a thin slice first?
Because it surfaces integration and architecture problems while they are still cheap to fix. It looks like slow progress for a few weeks and makes everything after it predictable.
How much should we test?
The flows where failure is expensive — authentication, payments, permissions, data export. Full coverage is rarely worth the cost; zero coverage on those flows is negligent.
What if our requirements change during the build?
They will. The domain model is designed for evolution and the phasing is structured so scope can be adjusted between phases rather than mid-phase, which is where change becomes expensive.
How do we know you are the right supplier for this?
You do not, from a page. What you can check is whether we describe the failure modes accurately, whether we tell you when something is not worth doing, and whether the scope we write has an explicit list of exclusions. A discovery call costs nothing and is the fastest way to find out, and a supplier unwilling to say what they will not do is telling you something either way.
Other solutions
Start a conversation
Tell us where you are now. We will tell you whether this is the right shape of engagement — including when a smaller piece of work would serve you better.
Get in touch