What 250 client builds taught us about how SMBs really run operations

Most small and medium businesses do not have an operations problem. They have a memory problem. After 250+ apps for 100+ businesses — many on Glide, many native — the same picture repeats with surprising fidelity: the work is getting done, the customers are mostly happy, and the people running it are exhausted.

Picture a Tuesday morning at one of these businesses. Six browser tabs are open — three of them spreadsheets that should agree but don't. WhatsApp is pinging: a customer is short two crates, and the one person who knew which supplier prefers which payment method just sent a polite resignation. The numbers leadership actually needs are spread across three sheets and a paper notebook. By 11 AM there will be more fires. The strategic part of the business is, in practice, the part nobody at the top ever gets to.

This pattern is the opening act. The rest of this post is about what 250 builds taught us about how to actually fix it — and the eight principles we apply on every project that does.

The five patterns we see in nearly every business

Underneath the firefighting are five recurring patterns. None of them are tooling problems. All of them are fit problems — the business has outgrown what it has, and the gap is filled by humans paying a tax in attention, time, and judgment every day.

A handful of people are the bottleneck for everything. Two or three people start the day responding to messages and end the day responding to messages. Every approval, escalation, and clarification routes through the same small group. Strategy slides because firefighting fills the day.

Things happen, but nothing is recorded. A coupon goes out. A refund clears. A staff member misses a shift. The events happen — the business operates — but no clean record exists afterwards. There is no audit trail when a vendor, customer, or auditor asks "what actually happened on the 14th?"

When a key person leaves, the business stops. Knowledge that lives in one head — supplier negotiations, dispatch routing, payment terms by client. When that head walks out, a founder steps in to fill the role under pressure, badly, while their own work piles up.

Tasks slip because nobody owns them. "I thought you were doing that." Things fall through the cracks because nothing in the system says whose name is next to which task. Approvals sit in chat threads. Status meetings paper over the gap without fixing the mechanic.

The data is everywhere, and admin time is the price. Bookings in one tool, payments in another, customer history in a third, ops notes in a chat group, a master spreadsheet that never quite reconciles. The team spends a real share of every week moving data between systems instead of doing the work the systems are supposed to support.

The patterns are the surface symptoms. What matters is what we've learned about building tools that actually fix them.

What 250 builds taught us about building tools that actually work

If those patterns sound familiar, the question worth answering isn't "which tool fixes them" — it's "what's the right way to think about building anything for a business that runs on real, custom workflows." Eight principles guide every project we ship.

1. We're business-functional experts first, technologists second

The stack matters, but it's downstream of understanding the business. By the time we've read the brief, sat with the team, and watched a Tuesday morning unfold, we already know roughly what we're going to build and roughly which tool will serve it. The technical decisions are the easy part. The hard part is figuring out what the business actually does and which 20% of that is worth automating first.

2. We map the whole business, not just the ask

A client almost never asks for the right thing on the first call. They ask for the thing that's most painful right now. We treat that ask as a starting point, not a brief. We map the surrounding workflow — what feeds into the painful thing, what comes out of it, who else touches it, what happens upstream when it breaks. Because we've seen 100+ businesses, we can usually anticipate the next three things leadership will need before they say it. That's why the v1 we ship is rarely just the v1 they asked for; it's the v1 that won't have to be torn up in three months.

3. We apply the 80/20 rule at design time

Most internal apps die from over-engineering, not under-engineering. We build the 20% of features that deliver 80% of the value first, and then we stop. The other 80% stays on a list, gets revisited after the team is using v1 for real, and most of it never gets built because it turns out it was not actually needed. Over-engineering at the start dilutes focus, slows shipping, and confuses the people who are supposed to adopt the thing.

4. We give every role its own surface

A driver app is not a dispatcher console. A finance reviewer should not be looking at the same screen as a service rep. We build role-specific portals — same database underneath where it makes sense, but tightly scoped views, permissions, and workflows for each role. On a recent build, a single underlying database powered separate surfaces for travellers, dispatchers, and admins, each scoped to exactly what that role needs. The system is the documentation; the workflow is the training. When the next person fills the role, they inherit the workflow, not a blank page.

5. We document for adoption — role guides plus walkthrough videos

We've watched too many builds die between "shipped" and "used." So every project we deliver ships with role-specific written guides and short walkthrough videos for each role. The team sees the person on screen do the thing they're supposed to do. Adoption stops being a separate change-management project and becomes a thirty-minute onboarding for any new hire.

6. We pick the right tool for the job — no religion about Glide vs native

Glide is right for some patterns: small teams, simple data shapes, fast iteration, internal-only audiences. Native — Next.js, Supabase, AI-assisted development — is right for others: heavier custom logic, public surfaces, integrations no off-the-shelf product ships with, real audit and security needs. We pick based on the work, not the platform. We've shipped 250+ apps across both, and the value has never been the platform. It's the judgment about which one fits this problem.

7. Security is non-negotiable, even on small internal tools

Audience size affects feature scope; it does not affect security posture. Every tool we ship has row-level security wired in, role-scoped access, secrets stored where they belong, and private-by-default surfaces. The Service Portal operations rebuild was driven partly by a security gap: service executives used to go straight into the e-commerce admin to issue coupons, and none of those actions were tracked. Closing that audit hole was the first thing the new system did. "It's just for our team" is not a reason to skip RLS; it's the reason an internal tool gets compromised the day someone's laptop walks off.

8. We build partnerships, not projects

Most of our clients are recurring. They start with one small build and stay with us as their business build partner because, within the first few months, we know how their business runs. That's the only way the 80/20 calls get made well — by people who understand the 80 and the 20. We become the cheapest place for the business to get its next problem solved, because we don't have to learn the business again every time.

The decision behind all of it

Underneath every one of the five patterns is the same mistake: defaulting to "buy more SaaS" when the actual need is custom. Standard tools are excellent for standard work — QuickBooks for accounting, Shopify for storefronts, a CRM for vanilla sales pipelines. If the workflow is genuinely standard, use the standard tool. Building custom there is a waste of money and time, and we'll tell a client to keep what they have every time.

But every business we've worked with has at least one workflow that isn't standard. Specific operations logic. Multi-stakeholder approvals. Industry-specific compliance. Integrations no off-the-shelf product ships with. When a business forces a custom workflow into a generic SaaS, the workflow bends to fit the SaaS's opinion — not the other way around. That's the trap. Most teams stay in it because the build path looks scary, and the SaaS path looks safe. In our experience, the SaaS path is what stays expensive.

Knowing where to draw that line — standard SaaS for standard work, custom for the work that defines the business — is the difference between SMBs that escape firefighting and the ones that don't. The patterns are the symptoms. The decision is the lever.

The takeaway

Most posts on this topic stop at the patterns. The patterns are the easy part. The hard part is the eight principles above, applied honestly, in service of the actual business in front of you. That's what 250 builds taught us, and it's what we ship every time.

If any of these patterns sound familiar, our case studies show how we've helped clients break out of them. If you'd rather talk specifics about your business, book a 30-minute conversation.