How do I know the build will be worth the cost?

You approve a written scope and price before a line is written, so you are never surprised by the bill. A senior with about a decade in development does the work, and every project clears two QA passes. Month to month support after, so you keep it only while it earns its place.

Can you build the kind of thing I need?

Most likely. We work in React, Next.js, Vue, Angular, Node.js, Python, PHP, WordPress, Shopify, Flutter, React Native, Swift, Kotlin, Laravel, and more, and we match the stack to what your project actually needs, not what we feel like using.

Can you take over my existing codebase?

Yes. We regularly pick up live projects, whether that is adding features to a custom app, rebuilding a WordPress site, or fixing an e-commerce store. We do a code review first and give you an honest read before we commit your money to it.

What happens after launch if something breaks?

You get month-to-month maintenance: bug fixes, security updates, performance monitoring, and small feature additions. No lock-in, so you keep it only as long as it is useful. A real senior replies within 1 business day when you need them.

How do I know the code is solid and not a first draft?

Every project clears two QA passes: automated testing, manual browser and device checks, accessibility, performance, and a security review. You get production-quality code, signed off by one named owner before it ships, not a rushed handoff.

When you hand it off, what do I own?

All of it. You get the complete source code, documentation, deployment guides, and admin logins, all in your accounts. We run a walkthrough with your team and stay on through a support period. The work and the access are yours, with nothing held hostage.

File · DEV-2026/§ 01 of 08 · Engineering practiceEngineering practice

← Practice index

~/your-org/your-app

Open · ready to mergecommit 8f4e2a1

Web and app development that ships every week, in a GitHub org you own from day one.

Custom web apps, MVPs, mobile apps, ecommerce, marketing sites, headless CMS, internal tools, and WordPress replatforms. Next.js, Payload, Postgres and React Native, all open source, on accounts in your name.

Get the free build audit See what we build

main · sample month: 25 commits · audit back in 4 days · month to month

Start the free build auditback in 4 days

Two fields here. The brief below arrives pre-filled, three fields to go.

your-week.md+3 −2

waiting for the monthly status call
“we’re about 80 percent there”
read the commit log any morning, in plain English
two QA passes before every release ships
the repo in your GitHub org from day one

✓ type check · ✓ tests · ✓ speed budget · ✓ human QA

File · DEV-2026/§ 02 of 08 · What we buildWhat we build

← Practice index

ten kinds of build · what week one looks like

What we build. And how each one starts.

Every project opens the same way: the repo is created in your GitHub organisation, the ship gates go on, and your audit findings become the backlog. Then week one goes differently depending on what you’re building. Pick yours and read the first week.

your-org/your-buildweek 0110 build types

Custom web apps

Software your business runs on: accounts, permissions, billing and the data model underneath.

What’s included

Multi-tenant architecture
Authentication and SSO
Role-based permissions
Stripe billing and subscriptions
Admin and customer dashboards
Typed REST and webhook APIs

$ git log --oneline --since="1 week"

a1c4f09chore(repo): initialised in your GitHub org, branch protection on
3e87b21ci: preview deploys, type check and speed budget wired
b58e2f1feat(auth): sessions, roles and organisation membership
44a0d96feat(db): data model and first migration
0d6ec73test: auth and permission suite, 41 cases green

By Friday of week one you have

The boring half done first: auth, roles and the data model
A permission test suite, so month four is a feature and not a rewrite
Typed end to end, so a whole class of bug fails the build instead of reaching a customer

StackNext.jsPostgresTyped API routesStripeVitest

repo in your org · reviews required on main · ts strict

Pick the one that matches what you need. Sample format, not a client’s repo.

Everything is priced per project after the audit, never estimated off a phone call.

Get my free build audit

File · DEV-2026/§ 03 of 08 · git loggit log

← Practice index

~/your-repo · git log --since="1 month"

A month of work, written out. Not the summary of it.

Below is a build sprint written out commit by commit, in the format you will get. The left side is what the machine records. The line underneath is what it means in English, and we write that line ourselves, on every single commit, because a log you cannot read is the same as no log at all.

This is what lands in your inbox every Friday, and it is the whole of the reporting. You will never wait on a status call to find out where your build is.

your-org/your-sitemain25 commits · sample format

commitspull requests files

25 commits

day 01a3f10c2chore: repo created in client org, NDA countersigned, access granted
Your repository exists, in your account, before we write a line. We are added as a contributor.
day 017e4b9d1chore(ci): lighthouse budget + typecheck gates enabled on every push
From now on, every change gets speed-checked and type-checked automatically before anyone looks at it.
day 02c19a4f8docs: build audit findings imported, 14 issues logged, 6 marked P0
The free audit becomes the backlog. Nothing gets invented later to fill a sprint.
day 032d80b17fix(mobile): form tap no longer blocks the page
Tapping a field on a phone used to freeze the page for a beat. It doesn't now.
day 0491cc3eaperf(home): defer non-critical scripts below the fold
The homepage stopped downloading things nobody had scrolled to yet.
day 055b7e0aafeat(cms): Payload collections scaffolded for pages, posts, authors
Your team now has somewhere to edit pages without calling a developer.
day 08e0d43c6fix(ssr): cache miss on /pricing, page was rebuilding on every visit
The pricing page was being rebuilt for every single visitor. Now it is built once.
day 094af2b95test: checkout flow covered end to end, 11 cases
Eleven ways a customer can go through checkout are now tested automatically on every change.
day 108c1d70ffeat(cms): preview links so editors see changes before publishing
Your editor can look at a draft on a real URL before the world does.
day 11b62fa04refactor(api): route handlers typed, 3 silent failure paths closed
Three places where an error could have disappeared quietly now shout.
day 121fe8cc9a11y: focus states + labels across all forms, WCAG 2.2 AA
Someone using a keyboard or a screen reader can now finish every form on the site.
day 157d2a601feat(search): site search shipped to preview for review
Search works. It is on the preview link, not live, waiting for you.
day 1630bbef4fix: search returned drafts to logged-out users
Caught in QA. Unpublished pages were showing up in search results. Fixed before ship.
day 17a58f13dperf(images): responsive sizes, homepage payload down
Phones stopped downloading desktop-sized images.
day 186e90c22chore(db): migration 004, orders table indexed on customer_id
A slow database lookup got an index. The admin order list stopped crawling.
day 19f21b8e7feat(i18n): Spanish locale wired, content model ready
The structure for a second language is in. Nothing is translated yet, that is your call.
day 220c74a19revert: "feat(analytics): third-party tag", added 190ms to first paint
We shipped a tracking tag, measured it, saw it cost speed, and pulled it back out.
day 239db3f05feat(analytics): same events, server-side, no client cost
Same data, moved off the visitor's browser. Speed back where it was.
day 245e1cc84docs: runbook written, deploy + rollback + env vars
Written instructions so a stranger could take over. In your repo, not in our heads.
day 25c807a3bfix(seo): duplicate canonical tags on paginated archives
Search engines were being told two different things about the same page.
day 2644f2d90chore: QA pass 1 complete, 7 issues raised
First set of eyes. Seven things found.
day 298a0e6b1fix: 7 QA issues closed, screenshots attached
All seven closed, with before-and-after screenshots in the ticket.
day 30d5b3c77chore: QA pass 2 complete, 0 blocking
Second set of eyes, different person. Nothing blocking.
day 302b91af6release: v1.2.0 to production, two QA passes clean
Live.
day 30ff07e2ddocs: sprint close, next sprint scoped and priced
What is next, and what it costs, written down before it starts.

ts strict · utf-8 · LF · main

Sample format, not a client’s log. A real client log stays confidential until they say otherwise.

Twenty-five commits. twenty-five sentences you can read.

That is the reporting. There is no second document.

Start with the free build audit

File · DEV-2026/§ 04 of 08 · How to read a logHow to read a log

← Practice index

Four checks. Thirty seconds.

How to read your log in thirty seconds.

You will get one of these every week, so it is worth thirty seconds to know what you are looking at.

Four things tell you where a build genuinely stands. They all work on the log above, and they are the same four things we design our own process around.

The dates, not the count

Work that happens daily looks daily. A run of steady dates going backwards tells you far more about a build's health than the raw number of commits does.

That is why we ship in small pieces through the week rather than one large drop at month end. It keeps the build reviewable, and it keeps your log worth reading.

The message, not the hash

update files tells you nothing. Neither does fixes or wip.

fix(ssr): cache miss on /pricing, page was rebuilding on every visit tells you exactly what was wrong, exactly where, and exactly what changed.

Every commit on your build gets written the second way, because a log you cannot read is the same as no log at all.

The reverts and the QA fixes

A log with zero mistakes in it has been tidied before it reached you, and a tidied log hides the part that matters.

Real engineering has a revert in it. Real engineering has fix: 7 QA issues closed in it. Ours does, up there, on day 22 and day 29.

We leave them in on purpose, so you can watch the QA process actually running rather than take our word that it did.

The merges and the review comments

A commit tells you one person wrote something. A merge with review comments on it tells you a second person read it before it reached your customers.

Every change on your build has both. That is what the two QA passes look like from the outside, and it is the single best predictor of whether a codebase stays cheap to work on in year two.

The next screen shows what that second pair of eyes catches.

File · DEV-2026/§ 05 of 08 · pull request #128pull request #128

← Practice index

your-org/your-site · #128 · requested changes

This is the part you are actually paying for.

A commit log shows you that work happened. It does not show you whether the work was any good.

So how do you check that?

You look at a pull request. A pull request is the moment before a change goes live, when a second person reads it and either says yes, or says not like that.

Below is the kind of mistake that passes every automated check, ships fine, and then costs money quietly for months before anybody notices. No test catches it. Someone who has shipped checkout code before catches it in about four seconds.

your-org/your-sitemain#128 · requested changes

commitspull requestsfiles

#128

Checkout: apply discount before tax

requested changes

show what shipped

   export async function totalFor(order: Order) {     const subtotal = sum(order.lines)+    const taxed = applyTax(subtotal, order.region)+    const total = applyDiscount(taxed, order.discount) +    const history = await db.orders.findMany({+      where: { customerId: order.customerId },+    })      return { total, history }   }

   export async function totalFor(order: Order) {     const subtotal = sum(order.lines)+    const discounted = applyDiscount(subtotal, order.discount)+    const total = applyTax(discounted, order.region) +    const history = await db.orders.findMany({+      where: { customerId: order.customerId },+      take: 50,+      orderBy: { createdAt: 'desc' },+    })      return { total, history }   }

review on applyDiscount(taxed, …)

This applies the discount after tax is calculated, so every discounted order overcharges the customer by the tax on the discount. It is small per order and it is wrong on every order. Tax goes last, always. Add a test with a 20 percent discount and a taxed line item so this cannot come back.

review on db.orders.findMany({ … })

This query has no limit on it. It is fine today with a few hundred orders and it will take the admin panel down at fifty thousand. Paginate it now while it costs ten minutes instead of a weekend.

ts strict · utf-8 · LF · main

Neither of those was a typo. Both would have passed every automated check we run. Both would have shipped.

That is what the second pair of eyes is for, and it is why nothing here goes out on one person’s judgment.

Every change goes through two QA passes before production: an automated set (types, tests, speed budget, accessibility) and a human one on real devices. You will see both in the log, because we commit the QA results too.

File · DEV-2026/§ 06 of 08 · git ls-filesgit ls-files

← Practice index

~/your-repo · main · what transfers

One repo. The whole stack you own.

Open the folder. There is nothing in here you need our permission to use.

Next.js, Payload, Postgres. All open source, all self-hostable, no proprietary CMS sitting in the middle holding your content. There is no licence to keep paying and no vendor to keep asking.

your-org/your-sitemain6 folders · all transfer

commits pull requestsfiles

app/ · Every page and route on your site

The actual pages. Standard Next.js. Any senior React developer opens this and knows where they are inside ten minutes.

components/ · Your design system, in code

Buttons, forms, cards, layouts. One set, used everywhere, so the site does not drift as it grows.

payload/ · The admin your team logs into

Your content model and your user roles. Open source, so there is no per-seat CMS bill arriving every year.

db/ · Your database, and every change ever made to it

Standard Postgres with numbered migrations. You can export the whole thing to a .sql file and take it anywhere.

.github/ · The checks that run before anything ships

Speed budget, type check, tests, accessibility. These keep running whether we are still here or not.

docs/ · How to run it without us

Deploy steps, rollback steps, environment variables, and where every third-party account lives. Written for a developer who has never met us.

ts strict · utf-8 · LF · main

~/your-repo · docs/OFFBOARDING.md · committed day 01

You leave on a Monday. Here is what Monday looks like.

Owning your build should mean something specific on the day you actually need it, not a line in a contract.

So here is exactly what it means, in five steps, committed to docs/OFFBOARDING.md in your repo during the first sprint rather than written up for you at the end. Print it. Hold us to it.

You remove our access. That is the entire process.

The repository was created in your GitHub organisation on day one, not ours. We are a contributor to it. You remove the contributor. Nothing moves, nothing gets migrated, nothing gets “prepared for handover” over four billable weeks. It was always in your account.

The accounts were already in your name

Hosting, database, storage, domain, analytics, error tracking. All created in your name, on your billing, from the start. We hold access, not ownership. There is no account of ours that your site depends on.

The instructions were written before you needed them

docs/ was committed in the first sprint, not assembled at the end when you asked for it. Deploy steps, rollback steps, environment variables, and where every third-party account lives. Written for a developer who has never met us, because one day that is exactly who is going to read it.

The next developer does not need us

The stack is open source and standard, so the pool of people who can take it over is every senior React developer on earth, not a shortlist we approve. And the commit log means they can read the history of every decision on the build without a single call with us.

Your work stays yours, before and after

A mutual NDA is signed before we touch anything. What you tell us does not become a case study, a screenshot, or a portfolio piece without you saying yes in writing.

You can leave after the first sprint. We would rather you stayed because the build is good, not because leaving is expensive.

File · DEV-2026/§ 07 of 08 · Free build auditFree build audit

← Practice index

~/audit · grovant audit --site=your.site

It all starts with commit zero.

Every engagement starts the same way, and it starts free.

Send us your site or your repo. An engineer runs it by hand and reads every result in context: Core Web Vitals against the public thresholds, page weight, type safety, ship checks, accessibility, search markup, repo hygiene. Four business days later a scorecard lands in your inbox, with each finding marked P0 or P1 and slotted into a sprint.

No call required. No deck. If you hire us, that scorecard becomes the first commits in your log. If you don’t, every finding still names a file and a line number, so whoever you hire next starts where we stopped.

Audit card · sample of the full findings format

Delivered to your inbox

FAIL
Slow interactions on mobile
A form tap blocks the page past the 200ms bar. Users feel it.
P0 · sprint 01
FAIL
Page weight
The homepage ships more than it needs. Unused code slows first paint.
P0 · sprint 01
WARN
Type safety
API routes are not typed, so bugs slip through.
P1 · sprint 02
WARN
Ship checks
No preview link, no speed gate, no type check before live.
P1 · sprint 02
PASS
Search markup
Schema on every template, sitemap builds itself.
clean
PASS
Repo hygiene
Main branch protected, reviews required, secrets kept out.
clean

LCP ≤ 2.5s · INP ≤ 200ms · CLS ≤ 0.10 · TTFB ≤ 800ms · public Core Web Vitals thresholds

Start commit zero.

Five fields. An engineer reads it and replies within 1 business day.

Capacity is limited on purpose: seniors do the work, so we take a few new engagements at a time. The audit is how we choose.

Mutual NDA before we clone anything. The repo is created in your org, not ours.

Read before you clone

What people ask before the first sprint.

Plain answers on ownership, cost, taking over existing code, and what happens after launch.

You approve a written scope and price before a line is written, so you are never surprised by the bill. A senior with about a decade in development does the work, and every project clears two QA passes. Month to month support after, so you keep it only while it earns its place.
Most likely. We work in React, Next.js, Vue, Angular, Node.js, Python, PHP, WordPress, Shopify, Flutter, React Native, Swift, Kotlin, Laravel, and more, and we match the stack to what your project actually needs, not what we feel like using.
Yes. We regularly pick up live projects, whether that is adding features to a custom app, rebuilding a WordPress site, or fixing an e-commerce store. We do a code review first and give you an honest read before we commit your money to it.
You get month-to-month maintenance: bug fixes, security updates, performance monitoring, and small feature additions. No lock-in, so you keep it only as long as it is useful. A real senior replies within 1 business day when you need them.
Every project clears two QA passes: automated testing, manual browser and device checks, accessibility, performance, and a security review. You get production-quality code, signed off by one named owner before it ships, not a rushed handoff.
All of it. You get the complete source code, documentation, deployment guides, and admin logins, all in your accounts. We run a walkthrough with your team and stay on through a support period. The work and the access are yours, with nothing held hostage.

Don't see your question?Send a quick message →

Reply · within 1 business day

File · DEV-2026 / Closing brief · Page 08 of 08

Day one is a repo in your name. Day thirty is a log you can read.

Start at commit zero. Four business days, free, no call. What comes back is one document: every finding ranked P0 or P1, each one pinned to a file path in your codebase.

One senior, named owner, you own every file.

Get my free build audit Book a 20-minute call

Month to month · cancel anytime · mutual NDA before we look at anything

Free audit · 4 days

The repo is in your org from day one

Get free audit

Web and app development that ships every week, in a GitHub org you own from day one.

What we build. And how each one starts.

Custom web apps

MVP builds

Mobile apps

Ecommerce builds

Marketing sites

Headless CMS

Internal tools & integrations

Replatform off WordPress

Performance retainer

Data migration

A month of work, written out. Not the summary of it.

How to read your log in thirty seconds.

The dates, not the count

The message, not the hash

The reverts and the QA fixes

The merges and the review comments

This is the part you are actually paying for.

Checkout: apply discount before tax

One repo. The whole stack you own.

app/ · Every page and route on your site

components/ · Your design system, in code

payload/ · The admin your team logs into

db/ · Your database, and every change ever made to it

.github/ · The checks that run before anything ships

docs/ · How to run it without us

You leave on a Monday. Here is what Monday looks like.

You remove our access. That is the entire process.

The accounts were already in your name

The instructions were written before you needed them

The next developer does not need us

Your work stays yours, before and after

It all starts with commit zero.

Start commit zero.

What people ask before the first sprint.

Day one is a repo in your name. Day thirty is a log you can read.