How we work

How we work.

Most agency sites are vague about this. Being specific costs us the occasional badly-matched project, which is rather the point.

Engagement

Four ways to work with us.

The right one depends on how well-defined the work is and who owns the direction. We will suggest one after the first conversation, and we will say why.

Fixed-scope project

A defined build with a clear end: a website, the first version of an application, a specific integration. Priced and scoped up front, with changes handled as changes and agreed in writing.

Fits when
You know what you want, and the requirements are stable enough to write down.
Poor fit when
The requirements are genuinely uncertain. Fixing the scope then just means fixing the wrong scope, and every useful discovery becomes an argument about the contract. A short paid discovery first is cheaper than that.

Ongoing retainer

An agreed amount of senior time each month for continuing development, maintenance and support of something already running. Priorities are set at the start of each cycle.

Fits when
The software is live and still evolving, and you need dependable availability rather than a fixed deliverable.
Poor fit when
You need a large push completed in a short window. A retainer paces the work; it does not compress it.

Fractional technical leadership

Technical leadership without a full-time hire. Architecture and technology decisions, review of work done by your own developers or by other vendors, evaluation of suppliers and candidates, and being the person you can call before signing something expensive.

Fits when
You are accountable for technical decisions and have nobody in-house qualified to make them. Common where a practice or a billing operation runs on software but employs no engineers.
Poor fit when
You want a developer on demand, or somebody on call when production breaks at midnight. This is neither. It is judgement, not capacity, and buying it as capacity wastes it.

Staff augmentation

Our engineers working inside your team, to your process, on your backlog, in your tools. You direct the work day to day.

Fits when
You have your own product management and a shortage of senior engineering capacity.
Poor fit when
You want somebody to own the outcome. In this model you own the direction, and we will not pretend otherwise once things get difficult.
Fractional technical leadership

Technical leadership without a full-time hire.

The engagement that turns the principal's experience into something you can actually buy, for organisations that depend on software and employ nobody who builds it.

A practice with a billing operation, a founder with a product and no technical co-founder, or a company whose software is built entirely by outside vendors all share the same problem: decisions with long consequences are being made by people who cannot evaluate them. Not because anybody is careless — because there is nobody in the room whose job is to know. Hiring a senior engineer to fill that gap is expensive, slow, and usually more capacity than the role requires.

What it covers

  • Architecture and technology decisions, made and written down with the reasoning attached, so they can be revisited by somebody else later.
  • Review of work produced by your in-house developers or by another vendor — code, estimates, proposals and the things a proposal leaves out.
  • Evaluating suppliers before you commit: whether the quote is realistic, whether the approach is sound, and what the contract does not say.
  • Technical input on hiring — what the role actually needs and whether a candidate can do it.
  • Being the call you make before signing something expensive, at the point where the decision is still cheap to change.

What it is not

  • Not a developer on demand. If you need code written, that is one of the other engagement models and we will say so rather than quietly billing leadership hours as implementation.
  • Not an on-call support line. Production incidents at two in the morning need a support arrangement, which is a different thing with a different price.
  • Not a rubber stamp. If we think a decision you have already taken is wrong, that is precisely what you are paying to hear.

The time is structured rather than open-ended: an agreed number of hours in each month, a standing call, and availability for the decisions that will not wait. What is agreed at the start is what gets invoiced.

Process

Four stages, and what each one produces.

These genuinely happen in this order. Each stage ends with something you can read, use or hold, so you can judge whether to continue.

The four stages of an engagementDiscovery produces a written understanding. Design produces screens and a data model. Build produces working software in increments. Handover produces code, documentation and a deployment.01Discoverya written understanding02Designscreens and data model03Buildworking software, in increments04Handovercode, docs, deployment
Each stage ends with something you can read, use or hold.

  1. Discovery

    What happens
    We learn the workflow from the people who actually perform it, review the systems already in place, and go looking for the awkward cases — the override, the correction after approval, the thing everybody does but nobody documented. Then we size the work and name the parts that are risky.
    What you do
    Give us time with the people who do the job, not only with their managers. Tell us the real constraints, including budget, deadline and any internal politics that will shape the answer.
    What you receive
    A written description of the workflow as we understood it, a list of decisions and open questions, and an estimate with its assumptions stated.

  2. Design

    What happens
    Screens for every state, including the empty, loading, error and permission-denied ones that get skipped and then cost a fortnight later. The data model and the role model are decided here, in the open.
    What you do
    Review it properly and say no early. A change at this stage costs an afternoon; the same change during build costs considerably more.
    What you receive
    Designs, a documented data model, a role and permission model, and a written record of the decisions and why they were made.

  3. Build

    What happens
    Working software in small increments on an environment you can open and use whenever you like. A regular call, and written updates in between. Your repository from the first commit, not at the end.
    What you do
    Look at it as it appears and respond to questions within a day or so. The cost of a slow answer is a developer guessing.
    What you receive
    Software you can use, source code you own, and a task board you can see without asking for a status report.

  4. Handover

    What happens
    Deployment to production, documentation written for somebody who was not involved, a walkthrough with whoever will maintain it, and every credential and account transferred into your name.
    What you do
    Nominate the person or firm who will look after it, and have them on the walkthrough.
    What you receive
    Source code, documentation, deployment, a runbook for the things that commonly go wrong, and a recording of the walkthrough if that is useful.
Candour

What we expect, and what you can expect.

Almost every engagement that goes wrong does so for one of the reasons on the left. It is worth agreeing on these before there is any money involved.

What we need from you

  • One person who can make a decision, and who is available to make it.
  • Access to the people who do the work today, including the one with the spreadsheet.
  • Feedback within a few days. Silence is the most expensive form of input.
  • The real constraints, early — budget, deadline, and anything political that will shape the solution.
  • Somebody on your side who will actually test the thing before it goes live.

What you get from us

  • A named point of contact who is one of the people doing the work.
  • Plain language. If we cannot explain a technical decision in terms of what it costs you, we do not understand it well enough yet.
  • Bad news early. A slipping estimate told late is worth nothing to you.
  • Decisions written down, so nobody is relying on what was said on a call in March.
  • Your source code in your repository from the first day, and your accounts in your name. If you decide to leave, nothing of yours is held hostage.
Practicalities

Hours, channels and timezones.

We work from Raipur, which is UTC+05:30. That gives a natural overlap of four to five hours with the United Kingdom and continental Europe during our afternoon. The United States is harder and we would rather be straight about it: meaningful overlap with the East Coast means one side moving. We hold a late block for calls with US clients and agree which days it falls on at the start of an engagement, rather than implying we are available at any hour.

Working hours
Not yet stated
Reply to email
Not yet stated
Late block for US calls
Not yet stated
Calls during a build
Not yet stated
Channels
  • Email for anything that should be a record.
  • A shared chat channel — yours or ours — for the quick things.
  • A task board you can read at any time, without asking anybody.
  • Video calls when a decision needs a conversation rather than a thread.

Still the right firm for this?

If the way we work sounds like it would suit yours, describe the problem and we will tell you honestly whether we are a good fit for it.

Start a conversation See how we work