Small business tech fixes that should not become rebuilds

Small business tech problems have a way of becoming bigger than they are.

A contact form stops sending email. A booking widget disappears. The SSL certificate expires. A domain points to the wrong host after a migration. Someone says, "Maybe we should just rebuild the site."

Sometimes that is right. Often it is expensive panic.

The quick-fix test

Start with one question: what customer path is broken?

• Customers cannot find the business
• Customers cannot email or message you
• Customers cannot book
• Customers cannot pay
• Customers cannot submit a form
• One workflow in an AI-built app is stuck

If the answer is one clear path, the first engagement should usually be a small fix or triage pass, not a redesign.

Problems that often start small

These are the kinds of issues that can often start as hourly quick-fix work:

• DNS records pointing to the wrong host
• Expired SSL certificates or certificate warnings
• Business email or Google Workspace records set up incorrectly
• Contact forms that no longer send submissions
• Booking widgets that broke after a provider or domain change
• M-Pesa Till, Paybill, STK push, or callback links that need checking
• Small content edits or broken links on a live site
• A failed deploy that needs rollback or config cleanup
• One AI-built app workflow that loops, crashes, or saves the wrong data

The point is not that every item is always simple. The point is that each one has a bounded first step: reproduce the failure, inspect the relevant system, make the smallest responsible fix, and verify the customer path.

When it is not a quick fix

A small issue stops being small when the failure crosses systems.

For example:

• Email, domain, site, and payments all broke after a migration
• The app has no clear owner, no deploy history, and no backup
• An AI coding tool has rewritten the same files several times without stabilizing the bug
• The payment path touches custom backend code, callbacks, secrets, and permissions
• The site is recoverable, but the stack is so fragile that the same outage will return

That is when the work should move from quick fix to Ship Safe, Always On, or a custom /scale engagement.

What to send for a quick fix

A useful brief is short:

1. The broken link or app screen
2. What customers were trying to do
3. The exact error message or screenshot
4. What changed recently
5. Who has access to the domain, hosting, email, or app repo

That is enough to tell whether this is a quick fix, urgent rescue, or a larger review.

Keep the fix honest

The honest version of quick-fix work is not "everything is KES 5,000." It is: small one-off fixes can start at KES 5,000/hour when the problem is bounded.

If the first hour shows the real issue is bigger, the right answer is to say that early. A small fix should not quietly turn into a rebuild.

If you have one specific problem with your site, email, booking, M-Pesa link, or AI-built app, start on /launch. If the issue affects a larger product or operating workflow, it likely belongs on /scale.