01
Fixed-scope project
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.
Best when the outcome is clear
01 / how we work
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
2 to 5 days
We read the systems, talk to the people doing the work, and write down what is actually 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.
1 to 2 weeks
Data model, integration contracts, screens where screens matter. Agreed before code, because the expensive mistakes are made here rather than in the implementation.
In two-week increments
Working software at the end of every increment, in an environment you can open. No demos assembled the night before, and no six-week silence.
Planned, rehearsed
Migration rehearsed on a copy first, a rollback that has been tested rather than assumed, and a date chosen around your clinic hours rather than ours.
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
These are not preferences. They are what makes a system somebody else can take over, which is the only real test of whether it was built well.
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.
Application code, infrastructure, database migrations and pipeline configuration. Nothing that matters is configured by hand in a console where nobody can see it.
Automated tests run on every change and a failing suite blocks the release. This is why we can ship on a Thursday afternoon without a knot in anyone's stomach.
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.
Structured logs, error tracking and uptime checks are configured before launch, not added after the first outage teaches everyone a lesson.
A runbook for each system: how to deploy it, how to restore it, who to call, and what breaks first under load. Written for the person on call at 2am, not for a proposal.
04 / commercial
01
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.
Best when the outcome is clear
02
An agreed block of engineering time each month for improvements, integrations and support, with a monthly written account of where it went.
Best when the system keeps evolving
03
Named engineers embedded in your team, working to your board and your standards. No layer of account management between you and the people writing the code.
Best when you have your own roadmap
05 / support
| Severity | Response | What it means |
|---|---|---|
| S1 | 1 hour, 24/7 | Production down, or patient-facing booking and intake unavailable |
| S2 | 4 working hours | Broken with a workaround, or an integration failing silently |
| S3 | Next working day | A defect that is not blocking work |
| S4 | Next increment | Improvements and requests, scheduled with you |
Response is when an engineer starts work and tells you so, not when a ticket is acknowledged by a robot. Resolution time depends on the fault and we will not pretend otherwise.
06 / questions
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.
The engineers you meet. 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.
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.
Two honest options. A monthly retainer where we keep it running, monitor it and improve it. Or 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.
On a retainer: one hour for a production outage, during coverage hours and out of them. Four working hours for something broken but working around. 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.
We would prefer it. One automation, one integration, 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
Fixed cost, 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
Tell us what you are building, or what is failing. An engineer replies, not a form autoresponder.
Meydan Free Zone
Dubai, United Arab Emirates
Spring City, PA 19475
United States