Discovery and process mapping
We start by watching how the work is done today — the spreadsheets, the WhatsApp groups, the workarounds. The workarounds are the requirements; they are where the real process differs from the one written down.
Operational systems built around how your business actually works — not around what an off-the-shelf product assumes.
What it covers
We start by watching how the work is done today — the spreadsheets, the WhatsApp groups, the workarounds. The workarounds are the requirements; they are where the real process differs from the one written down.
The data model is the decision you cannot cheaply reverse. We design it first, in detail, and walk you through it in plain language before a line of application code is written.
Backend, database, admin interfaces, role-based access, reporting and the integrations that make it useful. Built in two-week increments you can see running.
Getting your existing data in — cleaned, reconciled and verified — is a scoped part of the project, not something discovered in the final week.
Deployed to your cloud account, with infrastructure as code, documented runbooks, and a source repository you own from day one.
The first month after launch is when the real requirements surface. We plan for that rather than treating it as out of scope.
Who it's for
Businesses where the operational process is a genuine competitive difference, or is simply too specific for a product to fit. Typically 10–200 staff, running on spreadsheets or on software that has been bent past its limits.
We would rather lose the project than take one we are the wrong firm for.
What you get
This list goes into the proposal. If something is not on it, it is not in scope — and we would rather argue about that now than in month three.
Timeline & engagement
One workflow, one or two user roles, limited integrations — a scheduling tool, an approval workflow, an internal portal.
Several roles, real reporting, two or three integrations — the size most of our projects are.
Multi-module, multi-role, integrated with finance and third parties, replacing something business-critical.
A defined deliverable at a defined price, in milestones. Requires a discovery phase first, because a fixed price on an undefined scope is a fiction that ends badly for one of us.
Best for: Well-understood projects where the scope can genuinely be pinned down.
A paid discovery of one to three weeks producing a process map, a data model, a scope and a fixed quote. You can take that document to another vendor — it is yours.
Best for: Most projects. It is how we prefer to start.
A fixed monthly allocation of senior engineering, with priorities set at the start of each sprint.
Best for: Evolving products, or ongoing work after an initial build.
Related work
Fee defaulters, attendance and result cards in one place instead of five registers.
One system for enrollment, fee cycles, attendance, exams and parent communication — for academies that have outgrown registers and Excel.
A pipeline that matches your real sales process instead of the one your CRM assumes.
A sales pipeline shaped around how your team actually sells — for companies whose process does not fit a generic CRM, and who would rather own the code than rent the seats.
AI applied to the boring, expensive parts of your operation — document extraction, classification and review workflows — with confidence scoring and a human in the loop.
Learn moreLegacy .NET applications and databases brought back under control — incrementally, without a rewrite that stops the business for a year.
Learn moreSenior engineers embedded with your team, at your cadence — with the person who writes the code being the person you talk to.
Learn moreFAQ
We do not, which is why discovery is a separate paid phase. One to three weeks produces a process map, a data model, a scoped build plan and a fixed quote. If you decide not to proceed, you keep the document — it is genuinely useful on its own, and you can take it to another vendor.
Changes are expected; pretending otherwise is what makes fixed-price projects adversarial. Small changes inside a sprint we absorb. Larger ones get quoted and you decide. What we do not do is agree to everything and then quietly compromise quality to absorb it.
That is the intent. Standard stack, conventional patterns, documented, in your repository. If you hire an in-house .NET developer in two years, they should be able to read the codebase and be productive in a week. We have no interest in being structurally impossible to replace.
You do, on payment. Source code, data model, documentation — all yours. Where we reuse a component we have built before, you receive a perpetual, unrestricted licence to it and we say clearly which parts those are.
Frequently, yes. We can build alongside an in-house team, take one module while they take another, or lead architecture while they build. The dedicated-team engagement is designed for exactly that.
A 30-minute call, no slide deck. We will tell you whether this is worth building, whether an off-the-shelf product would serve you better, and roughly what it would take.
30 minutes · We reply within one business day.