Flat 30% off for Singapore 🇸🇬
Book a 30-min call →
21 days · from $1,999 · fixed

Ship It Live · internal tools sprint

The spreadsheet your team runs on, as real software in 21 days.

The shared spreadsheet everyone is scared to touch, rebuilt as software with permissions, history and no accidental deletions.

Enter to send
4.93★ / 32 reviews 75+ shipped Kickoff in 24h

Quick answer

A custom internal tool or admin dashboard can be built and in use by your team in 21 days from a fixed $1,999. That covers accounts and roles, your records and workflows, search and filtering, exports, an audit trail and reporting. Replacing a full ERP is a programme, not a sprint.

The plan

Day one to day 21, written down.

You get this schedule before you commit, not after. If a phase slips, that is mine to absorb — the price and the date were agreed before anything started.

The scheduleDay 1 → day 21
01Watch the current processDays 1–3
02DesignDays 4–9
03BuildDays 10–16
04Run both in parallelDays 17–19
05Cut overDays 20–21
  1. 1

    Days 1–3

    Watch the current process

    Your spreadsheet, your workarounds, and the steps people do from memory. The undocumented steps are the ones that break rebuilds, so they get found first.

  2. 2

    Days 4–9

    Design

    The screens your team lives in, designed for speed rather than beauty — keyboard-friendly, dense where density helps, and honest about the messy states.

  3. 3

    Days 10–16

    Build

    Data model, permissions, workflow and reporting. Your real data goes in during the build so you are testing against reality, not sample rows.

  4. 4

    Days 17–19

    Run both in parallel

    Your team uses it alongside the spreadsheet for a few days. Every gap surfaces now, while there is still time to close it.

  5. 5

    Days 20–21

    Cut over

    Data migrated, team trained, spreadsheet retired. Access handed over so you can add users without me.

What from $1,999 gets you

Everything needed to launch — nothing padding the invoice.

Accounts, roles and permissions — who can see and change what
Your actual records and the workflow that moves them along
Tables that stay usable at ten thousand rows, with search and filters
Bulk actions, CSV import and export both ways
An audit trail: who changed what, when, and what it was before
Reporting and a dashboard for the numbers you check every morning
Integrations with the tools you already use, where they have an API
Source code, design files and 30 days of support at handover

Who books this

Built for

Operations teams running the business out of a spreadsheet nobody trusts

Companies paying per seat for a tool that fits two-thirds of their process

Founders whose ops load is growing faster than they can hire

Real situations

Five ways this shows up, and what actually fixes it.

Not hypothetical — the shape of the problem before someone books this sprint, and the specific part of the build that resolves it.

Situation 1

The whole team runs on a spreadsheet nobody trusts anymore

Core operations depend on a shared spreadsheet that's grown so complex with formulas and manual workarounds that everyone is quietly afraid one edit will break something downstream.

Days 1-3 map the current process, including the undocumented workarounds, before building software that replaces the spreadsheet properly.

Situation 2

Paying per seat for a tool that fits two-thirds of the job

A team pays a growing monthly bill for off-the-shelf software that covers most of their workflow but forces constant workarounds for the parts it doesn't fit.

A tool built around the real process — not a vendor's generic model — removes the workaround entirely, with no per-seat cost afterward.

Situation 3

Operations load outgrowing the team's ability to hire fast enough

A growing company's operational workload is expanding faster than they can recruit and onboard people to manually handle it.

Roles, permissions and workflow logic absorb the repetitive parts of that load, so headcount doesn't have to scale linearly with volume.

Situation 4

No audit trail — nobody knows who changed what

A shared spreadsheet or loosely-permissioned tool has no history, so when a number changes unexpectedly, there's no way to see who changed it or what it was before.

An audit trail records who changed what and when, with the value it replaced — accountability the spreadsheet never had.

Situation 5

Data needs to move somewhere real before this even starts

Years of operational history live in a spreadsheet or a discontinued tool, and the idea of manually re-entering it into new software feels like its own project.

Migration is part of the sprint, with messy real data expected — cleaning rules get agreed during scoping, not discovered on cutover day.

The honest part

When 21 days is the wrong answer.

A fixed deadline only works when the scope genuinely fits inside it. These are the cases where I will tell you so rather than take the booking.

Replacing a full ERP or accounting system. Those carry compliance and integration weight that no three-week sprint should pretend to lift.

Integrating with legacy on-premise systems that have no API. Sometimes possible, never quick, and quoted only after I have seen what is actually there.

Processes nobody can describe. If two people disagree about how the work runs today, we fix that first — software will not settle it for you.

Scopefrom $1,999 · 21 days

Inside the 21 days

  • Accounts, roles and permissionswho can see and change what
  • Your actual records and the workflow that moves them along
  • Tables that stay usable at ten thousand rows, with search and filters
  • Bulk actions, CSV import and export both ways
  • An audit trail: who changed what, when, and what it was before
  • Reporting and a dashboard for the numbers you check every morning
  • Integrations with the tools you already use, where they have an API
  • Source code, design files and 30 days of support at handover

Quoted as one number before day one. A week running long is mine to absorb.

Outside the line

  • Replacing a full ERP or accounting system. Those carry compliance and integration weight that no three-week sprint should pretend to lift.
  • Integrating with legacy on-premise systems that have no API. Sometimes possible, never quick, and quoted only after I have seen what is actually there.
  • Processes nobody can describe. If two people disagree about how the work runs today, we fix that firstsoftware will not settle it for you.

Real work, sized and priced separately. You hear it before you book, not at handover.

Questions

Before you book

If one fits, use it, and I will say so on the call. Custom wins when per-seat costs have outgrown a build, when your process needs logic those tools cannot express, or when you need the data somewhere you actually own.

Spreadsheet → software cutover (without a quiet data disaster)

Migration is already on this page as a situation. The failure mode is quieter: you “go live,” then discover the sheet was still the real system for a week, and nobody can say which numbers are true.

Use a parallel run. Do not flip a switch on vibes.

Parallel-run checklist

WindowSource of truthWhat you prove
Week 1Spreadsheet (current)Workflow mapped; import path tested on a copy
Week 2Both (sheet primary)Tool mirrors the daily job; mismatches logged
Week 3Tool primary, sheet read-onlyOps run on the tool; sheet is archive + rollback
Cutover dayTool onlyNamed owner confirms; sheet frozen read-only

Rollback rule: If cutover fails, the sheet becomes primary again the same day. The tool stays up as secondary until the defect is fixed. Write the rollback owner’s name at kickoff — not after something breaks.

Who owns source-of-truth in week 3: one person (ops lead or founder), not “the team.” Software cannot settle an ownership fight.

What fits 21 days vs what becomes a platform project

Fits this sprintBecomes a different project
One team’s daily workflowMulti-department ERP
Roles + permissions you can list on one pageMatrix that needs a security committee
Audit log for creates/edits/exportsRegulated compliance program (HIPAA/SOC theatre)
Import from the current sheetDeep accounting sync with no API
Reporting the team already runs manually“Rebuild every SaaS we dislike” roadmap

If two people still disagree on how the work runs today, stop. Process first — this page already says that under “When 21 days is the wrong answer.”

Sibling sprints (pick the sharper slug)

Design-engineering acceptance (internal tools)

“It loads” is not done. Ops UI fails in the empty states — the morning someone deletes a row, the export that should not be allowed, the record with missing fields.

Done-when checklist (before cutover)

  • Empty, loading, and error states on the primary ops path
  • Permission model written down (who can view / edit / export / admin)
  • Audit events for create, edit, delete, export — enough to answer “who changed what”
  • Import dry-run on a copy of production data
  • Mobile path agreed (usable vs out of scope) — matches the existing FAQ honesty
  • Repo + hosting access in your accounts

Craft detail that usually matters here: dense tables, filters, and destructive actions. If you want the design side of that, see data table design best practices and best dashboard designs — then come back to ship the table as owned software.

When to stay on Airtable, Notion, or Retool

The live FAQ already says: if one of them fits, use it. This table is the booking filter — not a smear chart. Prices and limits change; re-check vendor pages before you budget.

Stay on the toolBook a custom sprint
Your process fits their primitivesLogic they cannot express without fragile glue
Seat cost is fine for the team sizePer-seat cost has outgrown a fixed build (verify your numbers)
Data living in their cloud is acceptableYou need the data and repo somewhere you own
Templates cover the jobAudit/export rules are product requirements

No invented competitor pricing here. Soft comparison only.

Where agents help on import QA (and where a human owns cutover)

Agents (including Grok Bot–style chores) are useful for reversible work: spotting import mismatches, drafting QA notes, summarizing diff rows. They do not own cutover day, permissions, or “this is now production.”

Agent can helpHuman must own
Flag rows that failed validationFreeze the spreadsheet
Draft a mismatch reportDeclare source-of-truth
Repeatable cleanup scripts you reviewRollback call

For the longer seat map, see What Is Grok Bot? Complete Guide and /shipitlive/ai-agent-in-21-days when the job is an approval loop, not an ops system of record.

Extra questions

Existing FAQ already covers Airtable/Notion/Retool, cost, migration, process change, mobile, permissions, and ownership.

Can we keep the spreadsheet as a read-only archive?

Yes — that is the default week-3 pattern. Freeze it, label it archive, and stop writing to it once the tool is primary.

Who hosts this after day 21?

You. Accounts, DNS, and the repo sit under your ownership at handoff — same rule as the rest of Ship It Live. Ongoing care is a separate conversation if you want it.

Can this internal tool become a customer-facing product later?

Sometimes. That is a scope change (auth, tenancy, design polish, support). Do not pretend the 21-day ops tool is already a SaaS MVP — use /shipitlive/saas-mvp-in-30-days when that is the real job.

21 days from now, this could be live.

A 30-minute call decides whether the scope fits. If it doesn't, I'll tell you what would.