Skip to content

How we work

What it's actually like to work with us.

Most studios publish a tidy diagram of five phases. That tells you almost nothing about what the next three months feel like. This page is the other information — what we need from you, how often you'll hear from us, and what happens when something goes wrong.

The shape of a project

  1. 01

    Scope

    Work out the real problem and fix the price.

  2. 02

    Plan

    Decide the structure before anyone builds it.

  3. 03

    Build

    Weekly demos against a link you can open.

  4. 04

    Harden

    Break it deliberately before customers do.

  5. 05

    Launch

    Go live, watch closely, stay reachable.

Timings differ by service — each service page carries its own week-by-week breakdown.

What we need from you

The project needs about three hours a week of you.

Not much, but not nothing. These are the things that decide whether a build runs smoothly or drifts.

  • One person who can say yes

    Not a committee. Someone empowered to approve a design, settle a disagreement and sign things off. Projects that stall almost never stall on the building — they stall waiting for a decision nobody is allowed to make.

  • Two or three hours a week

    Mostly in the first fortnight and around launch. Enough to answer questions, look at what we have made and tell us where it is wrong. If nobody on your side has that time, the project will take longer and end up further from what you wanted.

  • The awkward details early

    The legacy system nobody likes, the process that only works because Priya remembers the exception, the deadline that is actually immovable. These surface eventually. Surfacing them in week one is free; in week eight it is expensive.

  • Access to the accounts

    Domain, hosting, analytics, whatever already exists. If you have lost access, tell us early — recovering it can take days and it is a common reason launches slip.

  • Feedback that says why

    "I don't like it" is hard to act on. "It feels too corporate for our customers" we can work with. You do not need design vocabulary — just tell us the effect it is having on you.

How we communicate

You'll never wonder where it's got to.

The single most common complaint about developers is silence. This is how we avoid it.

  • One thread, not five

    We agree a single main channel at the start and keep the project in it. Decisions scattered across email, chat and calls is how things get built twice.

  • A demo every week

    Same day each week, on a live link you can open on your own phone. Short — usually fifteen minutes. If there is nothing worth showing, we say so rather than inventing progress.

  • Replies within one working day

    Usually much faster. We keep hours that overlap yours, so a simple question does not cost you a day. If something needs thought, you will get an acknowledgement while we think.

  • Written where it matters

    Calls are good for working things out and bad for remembering them. Anything that changes scope, price or a deadline gets written down and sent to you the same day.

  • You keep the link

    The staging link stays live and yours to share. Show it to a colleague, your partner, a customer — early reactions from people who are not in the project are worth a lot.

How money works

No invoice should ever be a surprise.

We don't publish prices because the honest number depends on the job. The mechanics, though, are the same every time.

  • Priced before it starts

    We work out what the job is, then name one figure for it. Not an hourly rate that quietly grows — a number you can plan around and take to whoever signs off spending.

  • Split into stages

    A deposit to begin, the balance on completion, and longer projects broken into stages tied to visible progress rather than dates on a calendar. You are never paying for something you cannot see.

  • Changes are quoted, not absorbed

    If you ask for something outside the agreed scope, we tell you what it costs that week and you decide. Nothing gets added quietly, and nothing appears for the first time on the final invoice.

  • Discovery is separate and small

    For custom software and AI work, the first stage — understanding the job — is priced separately and cheaply. At the end you own the scope document and you are free to take it elsewhere. That is the point of splitting it.

When things go wrong

Because sometimes they do.

Every studio's process page describes the happy path. This is the part that actually tells you who you're dealing with.

  • If we are running late

    You hear it the week we know, not the week it was due. Along with why, what it means for the date, and what we are doing about it. A deadline that quietly moves twice is worse than one honest conversation.

  • If the scope grows

    Some growth is normal — you learn things by seeing the thing. We price the change, you approve or decline it, and either answer is fine. What we will not do is absorb it silently and then resent it.

  • If we get it wrong

    We fix it, free, and that does not expire after thirty days. If we built something that does not do what we agreed it would, that is ours to put right. It is not a goodwill gesture.

  • If we disagree

    Sometimes you will want something we think is a mistake. We will say so once, clearly, with our reasoning. Then it is your business and your call, and we will build it properly rather than half-heartedly.

  • If you want to stop

    You can. You pay for the work done to that point and you take everything with you — the code, the accounts, the documentation. There is no exit fee and no hostage-taking.

What done means

Finished, not nearly-finished.

A project is done when all of these are true — not when the last feature was built.

  • It works on the phones and browsers people actually use, not just ours
  • It is live on accounts in your name, which you can log into
  • Anyone on your team who needs to update it has been shown how
  • Written instructions exist, so the knowledge is not just in someone's head
  • Monitoring is on, so a problem does not wait for a customer to report it
  • The 30-day support window starts, and our own mistakes stay free after it

Next step

Tell the chooms what needs building

Send the problem, not a spec. You'll hear back within 24 hours with a straight answer on what it takes, what it costs, and whether we're even the right chooms for it.