Custom Software for Small Business: 5 Red Flags When Hiring

Most small businesses that get burned on custom software didn't pick the wrong technology. They picked the wrong person to build it.

The bad part? The red flags were there before the contract was signed. The worse part? They're the same red flags every time. I'm going to walk through the five I see most often, explain why each one costs you money, and tell you what the alternative looks like.

If you want broader context on what to ask before you hire a developer — what to ask before you hire a developer, how handoffs should work, what "done" actually means — that's the longer guide. This post is the short version: the five things that should make you walk away.

Red Flag #1: They Won't Give You a Price Until You Pay for "Discovery"

This is the most common one, and it's the most expensive.

Here's how it works: you describe what you need. The agency says "great, we'd love to help — let's start with a discovery phase." That phase costs $5,000 to $25,000. It takes four to eight weeks. At the end, you get a slide deck, some wireframes, and a proposal for the actual build — which is a separate contract.

You just paid five figures for a quote.

I understand why agencies do this. Scoping software takes real effort, and they want to get paid for it. But the result is that the business owner is $10K deep before a single line of production code exists. And now there's sunk-cost pressure to keep going with that same agency, even if the build quote comes in high.

To be fair — paid discovery isn't always a scam. For projects with serious unknowns (data migrations, compliance requirements, gnarly legacy integrations), a scoping phase can genuinely reduce risk. But even then, the deliverables should be yours — requirements docs, architecture diagrams, wireframes — things you own and can take to another builder if you want. The red flag isn't "discovery exists." The red flag is when discovery is required just to get a ballpark, and the outputs lock you into continuing with that same shop.

What good looks like: A builder who can give you a meaningful price range from a single scoping conversation. Not a guess pulled from the air — a fixed-price range based on the features you described, the integrations you need, and the complexity of the data model. That range might be wide (say, $5,000 to $15,000 for a multi-feature app with integrations and user roles), but it exists, and you get it before you spend a dollar.

I publish my ranges at free project estimator. Five questions, about 90 seconds, and the range shows up on screen before the form asks who you are. That's the baseline — if the number works, I scope the specifics and give you a fixed quote within one business day.

Red Flag #2: Hourly Billing With No Cap

Hourly billing rewards slow work. That's it. That's the whole problem.

An agency billing $150 to $250 per hour has zero financial incentive to ship faster. If the project takes 400 hours instead of 200, they make twice as much. The client carries 100% of the overrun risk, and the developer carries 0%.

"But what about change orders?" Sure — scope changes should be handled explicitly. But that's different from an open-ended hourly tab where you don't know the total until the invoice arrives.

The Standish Group's CHAOS Report has tracked software project outcomes for years, and the pattern doesn't change: most software projects come in over budget, over schedule, or both. Hourly billing doesn't cause that, but it sure doesn't fight it.

What good looks like: Fixed price. The builder scopes the work, names a number, and if the build takes longer than expected, that's the builder's problem — not yours. Change the scope mid-project? Fine, that's a conversation and a revised quote. But the original scope stays at the original price.

My builds run from $2,500 for a simple focused app up to $20,000–$25,000 for advanced systems with real-time features, multi-tenancy, or AI components. The price is the price. I don't bill for meetings, I don't bill for revisions inside scope, and I don't send surprise invoices.

Red Flag #3: You Don't Own the Code

This one is quieter, and it bites later.

Some agencies and freelancers retain ownership of the codebase. You're licensing it. That means if you want to leave — hire someone else to maintain it, bring development in-house, or just move to a different platform — you either can't, or you're paying an exit fee to get your own project.

It also means you can't have another developer audit the code, fix a bug independently, or extend a feature without going back to the original builder. You're locked in, and lock-in is leverage they have over you.

I've seen this with platforms, too. Bubble, for example, is a no-code tool that works well for some teams in production — but your app lives on Bubble's infrastructure, in Bubble's proprietary format. You're buying a managed proprietary runtime. If you ever want to take the app code and self-host it somewhere else, or hand it to a traditional developer, you can't. That's not a dealbreaker for everyone, but you should go in knowing the exit risk is real.

What good looks like: The code lives in your repository from day one. Not at handoff — from day one. You own every commit. If you fire me tomorrow, you have the complete codebase, you can hand it to any developer who reads TypeScript and React, and you walk away clean. No exit fee, no licensing negotiation, no hostage situation.

Ask this question before you sign anything: "Who owns the code, and where does it live?" If the answer isn't "you, in your own repo," keep walking.

Red Flag #4: They Staff Five People on a Two-Person Job

Agencies love to throw bodies at projects. A project manager, a UX designer, a front-end developer, a back-end developer, a QA engineer, and a "technical architect" who shows up to the kickoff call and is never seen again. Six people, all billing hours.

The math on this gets ugly fast. If you're paying $175/hour across six people and they each bill 20 hours a week, that's $21,000 per week. A four-week project just cost $84,000. For what might be a Postgres database, a Next.js front end, and a Stripe integration.

I'm not saying every project can be a one-person job. Complex systems with real-time requirements, heavy compliance needs, or tight deadlines sometimes need a team. But the vast majority of custom software for small business — the internal tools, the client portals, the workflow automations, the dashboards — these are one or two-person builds.

Here's a real example. I recently built an automated content platform — fixed price, delivered in weeks. The system generates topic ideas from Google Keyword data, ranks opportunities, has Claude write long-form drafts against a custom voice profile, then routes each draft through Grok, Gemini, and ChatGPT for SEO review. When any two models agree on a change, Claude implements it. Every post runs through Sapling.ai to confirm it reads as human-written, image generation produces multiple images per post, and it publishes on schedule with Zapier pushing to Facebook and Google Business Profile. It even ships with its own analytics — individual user tracking, heatmaps, cohort analysis, funnel tracking.

That's a genuinely complex system. Multiple AI model integrations, automated editorial workflows, scheduling, social distribution, and built-in analytics that go deeper than Google Analytics on content performance. One builder. Fixed price. Shipped in weeks — not months.

An agency would have staffed that with a project manager, an AI specialist, a front-end developer, a back-end developer, a DevOps engineer, and a data analyst. Six people for three months. You do the hourly math.

What good looks like: Ask who's actually writing the code. If the answer is more than two people for a small-business project, ask why. Sometimes there's a good reason. Usually there isn't.

Red Flag #5: No Timeline, No Milestones, Just "We'll Keep You Updated"

If the developer can't tell you when you'll see the first working version, you're not buying software — you're funding someone's open-ended exploration.

Good custom software development for small business follows a pattern: scope, build, review, ship. You should know before signing what the milestones are, when the first reviewable version appears, what your involvement looks like at each stage, and when the project is done.

Here's what the timeline should actually involve on your end:

That's it. Maybe four to six hours of your time across a multi-week build. If someone's asking you for more than that — endless requirements meetings, "alignment sessions," weekly status calls with six people — that's process theater. It's activity that feels productive but doesn't ship software.

Recent Stack Overflow Developer Surveys show that AI coding tools have gone mainstream among professional developers. That matters here because AI-assisted development is a big part of why timelines have compressed. What used to take a team of four three months can now ship in weeks with a single experienced builder using tools like Cursor, Claude, and v0. The tools generate code fast; the builder's job is architecture, integration, quality control, and making sure the AI output actually works in production.

But that speed only shows up when one person is responsible for the whole thing. Add a traditional agency structure on top of AI tools and you get the worst of both worlds: AI-generated code that nobody fully understands because five different people touched it.

The Freelancer vs. Agency Question

Most of the red flags above apply more to agencies than to solo builders, and that's not a coincidence. Agencies have structural overhead — sales teams, project managers, office leases — that gets passed to you. That overhead isn't evil, but it means a $15,000 project at an agency might deliver the same output as a $7,000 project from an experienced freelancer.

The honest tradeoff:

The "risk if they disappear" row is the real concern, and it's valid. But it's mitigable — if you do it right. The code needs to live in your repo. There needs to be a README that covers setup, environment variables, and deployment. The stack should be standard (Next.js, Postgres, TypeScript — not some proprietary framework). And there should be a staging environment another developer can spin up without calling you to ask where the secrets live. With those pieces in place, any competent developer can pick it up. The disappearance risk only kills you when the code is locked in the builder's account, there's no documentation, and nobody else can read the stack.

Who Should NOT Hire Me (or Anyone Like Me)

I'm going to be direct about this because it saves us both time.

• Your SaaS bill is under $200/month. If you're paying $150/month for a tool that mostly works, custom software won't pay for itself. The math doesn't work. Keep the SaaS.
• You need a full-time embedded developer. I build and hand off. If you need someone sitting in your Slack five days a week for the next two years, you need a hire, not a project.
• You're deeply locked into an ecosystem you need to stay in. If your entire operation runs on Salesforce and you need a Salesforce customization, you need a Salesforce developer, not a custom build from scratch.
• You don't know what you want yet. I can help you scope, but I can't do your strategy. If you can't describe the problem in plain language — "I need X to do Y so that Z" — you're not ready for a build yet.

For everyone else — the owner who's duct-taping three SaaS tools together with Zapier, the operator paying per-seat prices that climb every time they hire, the business whose workflow doesn't fit any off-the-shelf product — that's where custom software for small business actually pays off.

How to Get a Real Number

You've read the red flags. Here's the actual next step.

Run the estimator at free project estimator. Five questions about what you're building — it takes about 90 seconds. Your price range shows up on screen before any form asks who you are. If the range makes sense for the problem you're solving, the form sends it to me, and you get a fixed quote within one business day.

No discovery phase. No hourly billing. No slide deck.

P.S. If you're not sure whether your problem is a custom build or just a better SaaS configuration, that's a fine question to bring to the scoping call. I'll tell you if the answer is "just use Airtable" — I'd rather save you money than sell you a build you don't need.