How we work

Specification first. Always.

Software projects rarely fail on the code. They fail because everyone agreed on what was being built and nobody wrote it down. Six months later there is no way to tell who was right. This applies to a fortnight of automation and to a platform a new business line depends on — so the process is the same for both.

The sequence

Five stages, in this order, every time.

The order matters. Each stage produces something you can hold, read and disagree with before the next one starts.

  1. Discovery conversation

    Forty-five minutes, no charge, at your premises if you'll have us. If we are replacing something, we want to see it — the spreadsheet, the whiteboard, the chit book — because most of what matters is in the workarounds, and workarounds do not survive being described in a meeting room. If we are building something that does not exist yet, the conversation is about the proposition, the parties involved and what has to be true for it to work.

    You are not committing to anything at this stage, and a fair number of these conversations end with us saying the problem does not need custom software.

  2. Written specification

    A priced deliverable in its own right. Plain language, feature by feature, covering what the software does, who uses it, what happens when things go wrong, and what it deliberately does not do.

    The open questions are listed as open questions rather than quietly assumed. That list is usually the most valuable page in the document, because those are the decisions that would otherwise surface halfway through the build.

    It is yours. If you take the specification to another developer and get a better price, that is a legitimate outcome and we have still done our job.

  3. Phasing and quotation

    Phase 1 is what you need in order to launch, or to operate. Everything else is named, priced where it can be, and deferred in writing — so a deferred feature is a decision on record rather than something that got forgotten.

    A feature moves into an earlier phase only by explicit agreement. Answering a question about something in a meeting does not promote it. That rule exists because scope creep almost always arrives politely.

  4. Build, with reviews you can see

    Fixed scope, agreed price, agreed instalments. You see working software at defined points rather than a status report, because a demonstration is the only status report that cannot be optimistic.

    Changes are estimated and agreed in writing before work on them begins. Not to be difficult — so that neither of us has to reconstruct, in month four, what was promised in month one.

  5. Handover

    Intellectual property in the software transfers to you on final payment. You receive the source code, the documentation and the credentials. We hold no standing access to your live system; where support access is needed it is requested, time-boxed, logged and approved by you.

    You should be able to take the whole thing to another developer and have them pick it up. If you cannot, we have built it wrong.

Working habits

The small disciplines that keep a project honest.

Every document is versioned

Each revision carries an entry recording what changed and why. When you ask in March why a decision was made in January, the document answers rather than our memory.

Questions are surfaced, not assumed

Where something is genuinely undecided, it appears in the specification as an open question with our recommendation next to it. Assumptions made silently are the ones that cost money later.

Root cause, not workaround

When something behaves wrong, we find out why rather than patching over it. Patched-over problems come back, usually at the worst moment.

Plain language, your register

Documents your team can read. If your staff speak in Singlish on the floor, the training and the interface should not be written in consultancy English.

You own your data

You are the data controller. Exports are available in a usable format throughout, not as a favour at the end. Personal data handling follows PDPA obligations.

We say when it isn't us

Regulatory classification, tax treatment, employment rules, clinical wording. We will frame the question precisely so your adviser can answer it, then stay out of it.

What it costs to find out

The discovery conversation is free. The specification is quoted before it starts, as a fixed price, and delivered whether or not you go on to build with us.

Build work is quoted per phase at a fixed price against an agreed scope, with payment in instalments tied to delivery rather than to the calendar.

Before you commit

Check the grant position first.

If you intend to apply for EDG or PSG support towards this work, the application has to go in before anything is signed and before any money moves. We will hold the start date while you find out.

This applies whatever we are building — the sequence is about the contract, not about the kind of software.

Next step

Start with a conversation, not a proposal.

Forty-five minutes, no charge, and no obligation at the end of it. We look at how the work gets done today. If the honest answer is that you don't need software built, we will say so.