Skip to content
How we work

A process you can check on any day

Six stages, each with a duration and something you receive at the end of it. No black box, no status percentages, no month of silence followed by a surprise.

The engagement

From first call to handover

Timings below are typical for a mid-sized product build. Smaller sites compress the middle stages; long retainers repeat stages three to five every sprint.

  1. 01

    Discovery call

    30 minutes, free

    We walk through what you are building, who it is for, and what has to be true for the project to count as a success. You leave with a rough scope, a rough number and an honest read on whether we are the right team.

    You receive: Written scope summary within 24 hours

  2. 02

    Proposal & fixed scope

    2–3 days

    A written proposal: milestones, deliverables, timeline, price and explicit exclusions. No hourly surprises — you approve a scope, and changes to it are quoted before any work starts.

    You receive: Proposal, contract and milestone schedule

  3. 03

    Architecture & design

    Week 1

    Data model, API contracts and infrastructure plan on paper before code. UI work starts in Figma so you approve screens rather than reviewing half-built pages.

    You receive: Architecture doc, ER diagram, approved designs

  4. 04

    Build in weekly sprints

    Bulk of the project

    Working software every week on a staging URL you can click through. A short written update each Friday: what shipped, what is next, anything blocking. You are never guessing where the project stands.

    You receive: Staging environment, weekly demo and written update

  5. 05

    Test, harden & launch

    Final 1–2 weeks

    Automated tests in CI, load and failure-path testing, security review, performance budgets, then a rehearsed deploy with a rollback plan. Launch day is uneventful by design.

    You receive: Test suite, CI pipeline, production deployment

  6. 06

    Handover & support

    Ongoing

    Documentation, a recorded walkthrough and a 30-day warranty on everything we shipped. If you want us to keep operating it, a maintenance retainer picks up from there.

    You receive: Docs, walkthrough video, 30-day warranty

Weekly rhythm

What you get every week

The whole point is that you never have to ask how it is going. Three things land on a predictable schedule for as long as the project runs.

A staging URL that is current

Deployed from the main branch on every merge. You can open it any day of the week and see exactly where the build stands, on your phone or your laptop.

A written update every Friday

What shipped, what is next week, what is blocked and anything that moved the estimate. Three minutes to read, archived so you can look back at any point.

A demo or a recorded walkthrough

A live call if the week's work needs discussion, a five-minute Loom if it does not. Either way you see the software running before you are asked to sign anything off.

Communication

Async first, with a real overlap window

We are remote and so are most of our clients. That works when the defaults are written, searchable and time-zone tolerant.

Working hours
Mon–Sat · 9:00–19:00 IST (GMT+5:30) · Async updates daily
Response time
Replies within 4 business hours
Overlap window
At least four hours with UK and European teams, and an early-morning block with US East Coast. West Coast clients get a fixed call slot rather than ad-hoc availability.

Slack or your existing channel

We join your workspace as guests, or set up a shared channel. If your team lives in Teams or Discord, we use that instead. We do not ask you to adopt a new tool for our convenience.

Email for anything contractual

Scope changes, approvals and invoices go to email so there is a searchable record outside a chat history that may get archived.

Loom for anything visual

Explaining a UI decision or a bug is faster in two minutes of screen recording than in twenty messages. You can watch it whenever your day allows.

Decisions get written down wherever they are made. If something important is agreed on a call, it is in your inbox the same day.

Estimation

How we arrive at a number

Estimates go wrong in predictable ways. This is the sequence we use to avoid the usual ones.

  1. 1

    Break it into things that can be finished

    We decompose the scope into units small enough to complete in under two days. Anything bigger than that is not an estimate, it is a hope.

  2. 2

    Price the unknowns separately

    A third-party API nobody on the team has used, a legacy database with no documentation, an unclear compliance requirement. These get flagged and either time-boxed or moved into a paid spike.

  3. 3

    Add the work everyone forgets

    Empty states, error handling, admin screens, migrations, staging environments, code review and QA. In most projects this is 30 to 40 percent of the build and it is the usual reason quotes go wrong.

  4. 4

    Quote a range, then commit to a number

    You see the range and what would push the project to the top of it. Once the scope is signed, the number is fixed and the risk of being wrong is ours.

If we cannot estimate something responsibly, we say so and propose a short paid discovery instead of inventing a figure. That has cost us work. It has never cost a client a failed project.

Quality gates

What has to pass before anything ships

These run on every project regardless of size or budget. They are the difference between a demo and something that survives real traffic.

Tests run in CI

Unit tests on business logic, integration tests on API endpoints, Playwright on the paths that make money. A red pipeline blocks the merge, no exceptions for deadlines.

Every change is reviewed

Nothing reaches main without a second engineer reading it. Reviews cover correctness, naming and whether the next person will understand it in six months.

Performance budgets

Bundle size and Core Web Vitals thresholds are checked on each pull request. If a change makes the app measurably slower, we deal with it before it ships, not after launch.

Security review before launch

Auth and permission paths, input validation, dependency audit, secret handling, rate limiting and the OWASP basics. Findings are written up and fixed, not just noted.

A rollback plan that has been tested

Reversible migrations, versioned deploys and a documented way back to the previous release. We practise the rollback on staging before the production deploy.

Errors go somewhere a human looks

Sentry or an equivalent wired up before launch day, with alerts routed to a channel your team can see. Silent failures are the ones that cost the most.

Why teams stay

What tends to be different here

Four commitments that shape everything above. They are also the things clients bring up when they refer us.

Fixed scope, fixed price

You approve a written scope and a number. Change requests are quoted separately, so the invoice at the end matches the one at the start.

Weekly working software

A staging URL from week one and a demo every Friday. Progress you can click, not a status percentage in a spreadsheet.

Production, not prototypes

Tests, CI, monitoring, backups and a rollback path ship with the build. A demo that cannot survive real traffic is not finished.

Handover by default

Documentation and a walkthrough at the end of every project, whether or not you retain us. Lock-in is not our business model.

Handover

Leaving you able to run it without us

The end of a project should be a transfer, not a dependency. Everything below happens whether or not you take a retainer afterwards.

Documentation written for the next engineer

Architecture overview, data model, environment variables, deployment steps and the decisions we made along with why. Kept in your repository, not in a wiki you lose access to.

A recorded walkthrough

A screen recording covering the codebase layout, how to run it locally, how to deploy and how to handle the routine operational tasks. Your team can rewatch it when someone new joins.

30-day warranty

Defects in what we shipped get fixed at no cost for 30 days after launch. That covers bugs in our work, not new features or changes of mind.

No lock-in, by design

Your repository, your cloud accounts, your domain, standard open-source tooling throughout. If you want to move to an in-house team or another agency, everything you need is already yours.

Retainers are optional

Plenty of clients take the documentation and run the product themselves. Others keep us on for monitoring and a monthly block of hours. Both are normal, and we price the build the same either way.

Compare retainers

Ready to see this run on your project?

The first stage costs nothing. Book a 30-minute call and you will have a written scope summary within a day, whether or not you work with us.

Replies within 4 business hours · No obligation · You keep the scope document