Every growing company eventually hits the internal-tool question. Ops is managing orders in a shared Google Sheet. Sales has a CRM spreadsheet that half the team uses. Support keeps customer notes in Notion, Linear, and email, depending on the person. Someone asks: “should we build a real tool for this?”
The wrong answer costs a lot. Build too early and you spend three months of engineering time on a problem a spreadsheet was handling fine. Build too late and the workarounds have calcified into tribal knowledge that’s hard to unwind. Below is the framework we use when clients ask us.
The false dichotomy
Most teams treat this as “spreadsheet vs custom app.” The real spectrum has five steps:
- Shared spreadsheet or document
- No-code tool (Airtable, Notion databases, Coda) with some automation
- Low-code platform (Retool, Tooljet, Superblocks) wired to your real database
- Lightweight custom app built on top of your existing stack (e.g. a Next.js admin surface over the same Postgres your product uses)
- Full custom internal platform with its own ops, auth, and roadmap
Each step solves a different scale of problem and costs a different amount to run. Jumping three steps at once is almost always a mistake.
The signals that say “stay on a spreadsheet”
- Fewer than 5 people touch it. Real-time collaboration on a small team is what spreadsheets are good at. Don’t move off until it hurts.
- The process is still changing. If ops is still figuring out the workflow, a spreadsheet’s flexibility is an asset. Codifying a half-formed process in software slows iteration.
- No integrations are required. The moment you need to push data to Stripe, pull data from Intercom, or trigger actions in another system, spreadsheets get awkward.
- Errors aren’t expensive. If a typo means an email goes to the wrong person (bad, fixable) rather than the wrong customer getting charged (bad, unrecoverable), you have room to keep the lightweight setup.
The signals that say “it’s time”
- Data consistency is breaking. Two people have edited the same row with different values. The “master” spreadsheet has three copies floating around. Someone accidentally deleted a column and didn’t notice for a week.
- You’re duplicating effort across tools.Customer info lives in four places. Updates in one don’t propagate. Someone’s job has become keeping tools in sync.
- Access control matters. Not everyone should see everything, but spreadsheets give you blunt instruments. You need role-based permissions and audit trails.
- You’re hiring ops people to paper over the system.If you’re adding headcount whose entire job is maintaining workarounds, the tool is costing more than software would.
- Customer-visible mistakes are happening. Orders shipped to the wrong address, invoices with typos, onboarding steps skipped. Errors are no longer internal.
- Compliance or legal requirements are emerging. SOC 2, GDPR, HIPAA, or industry-specific regulations usually require audit logs, access controls, and data residency guarantees that spreadsheets can’t provide.
Before you jump to custom
When the signals tip, the next move is usually not custom software. Try the no-code or low-code step first.
Airtable or Notion databases give you structured data, basic views, relations, and permissions, most of what spreadsheets lack, for a fraction of the cost and zero engineering time. For many ops teams, this is the right permanent home.
Retool, Tooljet, or Superblocks let you build a proper UI over your actual database, with role-based access and workflow automation. You get 80% of a custom internal app in a week, and most workflows genuinely don’t need the other 20%. These tools have real limits at scale (performance, cost per seat, developer experience as complexity grows) but they’re the right stop for most teams.
The case for skipping to custom software is when you’ve hit real constraints on the intermediate tools: seat costs crossing $50k/year, performance problems on large datasets, compliance requirements that no-code platforms can’t meet, or deep integration with your product that would be convoluted on Retool.
When custom is the right answer
Build custom when the tool is the business, not just a support system. If your ops workflow is a competitive differentiator, faster fulfillment, better margin structure, unique customer experience, and scale is growing, a purpose-built internal platform pays back the investment. Same if you have regulatory requirements that no-code can’t meet, or if the tool needs to be extended by engineers every week with logic that’s specific to your domain.
Custom also makes sense when you’ve already been on Retool for 18 months, hit the ceiling, and now need to rebuild. The intermediate tool served its purpose, it let ops get real work done while the business figured out which parts of the workflow matter. The rewrite is cheaper because you know exactly what to build.
Our default recommendation
For most companies asking this question for the first time: stay on Airtable or move to Retool over a real database. Both are fast to stand up, reversible, and enough for most ops workflows. Revisit in a year. If you’ve outgrown them, if the signals in the second list keep piling up, then build custom, and do it on the same stack as your product so your engineering team can maintain it without extra expertise.
The only situation where we’d skip intermediate tools entirely is regulated industries or integrations that the intermediate layer can’t do cleanly. Otherwise, buy your way up the ladder.