01
Fixed-scope project
It is a defined build with a written scope, a fixed price and a date. Change is handled as a written change, not as an argument at the end.
It is best when the outcome is clear.
01 / how we work
There are five phases, and you can stop after the first.
Discovery is fixed cost and the output belongs to you whether or not we build it. Everything after that is delivered in two-week increments you can open and use, so you are never told what progress looks like without being shown it.
02 / phases
These are the five phases.
01
Discovery comes first.
2 to 5 days
We read the systems, talk to the people doing the work, and write down what is happening. You leave with a scope, an architecture outline, a risk list and a price. The document is yours whether or not we build it.
02
Design comes before code.
1 to 2 weeks
We agree the data model, the integration contracts and the screens, where screens matter, before any code is written, because the expensive mistakes are made here rather than in the implementation.
03
The build is delivered in increments.
It comes in two-week increments.
There is working software at the end of every increment, in an environment you can open. There are no demos assembled the night before, and no six-week silence.
04
The cutover is planned and rehearsed.
It happens on a date you choose.
The migration is rehearsed on a copy first, the rollback has been tested rather than assumed, and the date is chosen around your clinic hours rather than ours.
05
We run it, or we hand it over.
It is monthly, or handed over.
We keep it running, or we hand it to your team with the documentation and the access to do it themselves. Both are real options and we will tell you which one we think you need.
03 / standards
This is what every build is held to.
These are not preferences. They are what makes a system somebody else can take over, which is the only test of whether it was built well.
The accounts are yours from day one.
Repositories, cloud accounts, domains and third-party subscriptions are created in your name and billed to you. Leaving us costs you a permissions change, not a migration.
Everything is in version control.
That includes application code, infrastructure, database migrations and pipeline configuration. Nothing that matters is configured by hand in a console where nobody can see it.
Tests run before the deploy.
Automated tests run on every change and a failing suite blocks the release. This is why we can release on a Thursday afternoon.
Environments are reproducible.
Staging matches production closely enough to be worth having. If a bug only appears in production, that is a fault in our setup, not bad luck.
Observability is there from the start.
Structured logs, error tracking and uptime checks are configured before launch, not added after the first outage.
The documentation is something you can act on.
There is a runbook for each system that says how to deploy it, how to restore it, who to call, and what breaks first under load. It is written for the person on call at 2am, not for a proposal.
04 / commercial
There are three ways to engage.
02
Monthly retainer
It is an agreed block of engineering time each month for improvements, integrations and support, with a monthly written account of where it went.
It is best when the system keeps evolving.
03
Engineers by the month
Named engineers are embedded in your team, working to your board and your standards. There is no layer of account management between you and the people writing the code.
It is best when you have your own roadmap.
05 / support
These are the response targets on a retainer.
| Severity | Response | What it means |
|---|---|---|
| S1 | 1 hour, 24/7 | Production is down, or patient-facing booking and intake are unavailable. |
| S2 | 4 working hours | Something is broken but has a workaround, or an integration is failing silently. |
| S3 | It is the next working day. | It is a defect that is not blocking work. |
| S4 | It is the next increment. | These are improvements and requests, scheduled with you. |
Response is when an engineer starts work and tells you so, not when a ticket is acknowledged by an automated reply. Resolution time depends on the fault and we will not pretend otherwise.
06 / questions
These are the questions people ask before they sign.
How long does discovery take and what does it cost?
It takes two to five days depending on how many systems are involved, at a fixed price agreed before it starts. You get a written scope, an architecture outline, a risk list and a price for the build.
The document is yours. If you take it to another firm, that is a legitimate outcome and it is why the price is fixed rather than a free pitch we have to recover later.
Who does the work?
The engineers you meet do the work. There is no account layer between you and the people writing the code, and no arrangement where a senior engineer wins the work and a junior delivers it without you being told.
What if the estimate is wrong?
On a fixed-scope project, our estimate being wrong is our problem, and we absorb it. What is not covered is a change of scope, which is handled as a written change with its own price and its own date rather than as a difficult conversation at the end.
How do you handle support after launch?
There are two honest options. The first is a monthly retainer where we keep it running, monitor it and improve it. The second is a handover, where your team takes it with the documentation, the runbooks and the access to do the job properly.
We will tell you which one we think fits. A system with one integration and low change does not need a retainer, and selling you one anyway would be the easy thing to do.
What are your response targets?
On a retainer, the target is one hour for a production outage, during coverage hours and out of them. It is four working hours for something broken with a workaround, and the next working day for everything else.
These are targets we hold ourselves to and report against monthly, not a contractual guarantee dressed up as one.
Can we start small?
We would prefer it. Start with one automation, one integration, or one page that has to work. A small piece delivered properly tells you more about whether to keep working with us than any proposal, and it is a cheaper way to find out.
07 / next
Start with discovery.
It is fixed cost, it takes two to five days, and the document is yours either way. It is the cheapest way to find out whether we are any good.
Start a project08 / contact
Get in touch.
Tell us what you are building, or what is failing. An engineer replies, not a form autoresponder.
Dubai
Meydan Free Zone
Dubai, United Arab Emirates
United States
Spring City, PA 19475
United States