Before you hire a developer, decide one thing first: do you actually need a custom build, or do you need a simpler fix. The safest hire is the one who helps you choose the right level of solution before they start writing code.
A lot of expensive mistakes start the same way: a business owner says, “I think I need an app,” when the real answer might be a better website, an off-the-shelf tool, or a small automation. Don’t hire the first person who eagerly says yes. Hire the one who slows down long enough to figure out what problem you’re actually paying to solve.
The decision: hire a custom developer or buy/patch something simpler?
Here’s my plain recommendation: only hire a developer for custom work when your process is specific to your business, the off-the-shelf options are creating real friction, and you know what success looks like.
If your need is standard — brochure website, online store, booking, contact forms, basic CRM, simple email flows — buying or using a proven platform is usually the smarter move. If your need is unusual — syncing odd systems, replacing spreadsheet chaos, building internal tools, creating a client portal, or automating a workflow nobody sells well — that’s where custom work starts making sense.
If you’re sorting out that difference, these related reads may help: Template Website or Custom Build? The Better Choice for Your Business and Custom Software vs SaaS: Which Fits a NW Arkansas Small Business?.
Factor 1: Is the problem really custom, or just annoying?
Not every annoying process deserves software.
That sounds obvious, but it gets missed constantly. A messy process can feel like a software problem when it’s really a people problem, a policy problem, or a “we have three versions of the spreadsheet” problem. If the workflow is broken, automating it is like paving over potholes without fixing the roadbed. You get a smoother mess.
Ask the developer this: “Should we build this at all?”
If they can’t answer that honestly, I’d be cautious. A good developer should be willing to say, “No, don’t build that yet,” or “Use existing software for this piece and custom work for the gap.” Gartner and plenty of real-world projects point the same direction here: standard problems usually deserve standard tools.
A few quick examples:
- Simple marketing website: probably don’t custom-build from scratch
- Basic ecommerce store: usually start with Shopify or another proven platform
- Internal job tracking nobody on your team likes using: maybe custom
- Data being re-entered across multiple systems every day: often a strong automation or integration case
- Client portal with very specific rules and permissions: often custom
I’ve written more about this exact trap in Thinking About Hiring a Developer? Start With the Cheapest Useful Fix.
Factor 2: Can they define the job before they price the job?
This is where a lot of bad hires look good at first.
If someone gives you a confident fixed quote for a fuzzy idea with no discovery, no requirements work, and no hard questions, that’s not reassuring. That’s like a contractor pricing a building before asking about the foundation, plumbing, or whether you want one story or three.
The Project Management Institute has repeatedly pointed to weak requirements as a major cause of project failure. In plain English: if the job isn’t defined clearly, the budget and timeline usually won’t be either.
Ask these questions:
- What exactly are you delivering?
- What is not included?
- How do you handle change requests?
- How will we review progress? Weekly demos? Milestones?
- How do we decide the project is done?
That last one matters more than people think. You want acceptance criteria, not vibes. “A working client portal” is vague. “Users can log in, view invoices, download PDFs, and submit support requests” is testable.
If you need help comparing proposals, read How to Read a Software Proposal Without Missing the Expensive Parts.
Factor 3: What happens after launch?
Most buyers focus too hard on the build and not enough on the handoff.
That’s backwards.
A website, app, or automation is more like a truck than a painting. You don’t just buy it and admire it. It needs fuel, maintenance, repairs, and paperwork. If nobody talks about updates, backups, monitoring, and support, you are not buying a finished business tool. You are buying a future problem.
Before hiring, ask for a side-by-side answer on these:
- Who owns the code, design files, domain, hosting account, and data?
- Do I get admin access to everything?
- Will I receive documentation?
- Who handles updates and dependency patching?
- What happens if something breaks on a Friday afternoon?
- Can another developer take over later?
This is especially important for small businesses in places like Northwest Arkansas and the surrounding region, where you may want a local person who understands the business context and can hand things off cleanly if needed.
For custom tools and automations, I’d rather hire the developer who gives a narrower scope and a realistic maintenance conversation than the one who promises the moon and disappears after launch.
Factor 4: How do they handle security, testing, and failure?
This is the unsexy part, which is exactly why it gets skipped.
But Verizon’s breach reporting has shown for years that web apps are a common attack target. IBM and the broader QA world have also made the same point from another angle: bugs are much cheaper to catch early than late. So ask about security and testing before you sign, not after something goes wrong.
Here’s the simple buyer version of what to ask:
- How will you test this before launch?
- What parts are automated versus manually checked?
- How do you prevent updates from breaking existing features?
- How do logins, permissions, and admin access work?
- Where are passwords, API keys, and other secrets stored?
- What gets logged if an automation fails silently?
- Is there a human override step for risky automations?
That last one matters a lot for automation. A bad automation can fail quietly, duplicate actions, or push bad data into multiple systems at once. It’s like giving a forklift to someone without brakes. Efficient right up until the collision.
If you’re hiring for workflow work, start by looking at Business Automation and ask whether the fix is truly custom or just a cleaner integration.
Factor 5: Are you hiring a coder, or a translator?
The best developer for a small business is not the person who uses the most technical language. It’s the one who can translate business goals into trade-offs you can actually understand.
You should be able to ask, “Why this approach instead of another one?” and get a straight answer in normal English.
Here’s the breakdown I’d use:
- Bad fit: says yes to every feature, skips discovery, talks mostly about tools
- Better fit: asks about workflow, users, edge cases, and what success looks like
- Bad fit: treats launch as the finish line
- Better fit: talks about ownership, maintenance, support, and handoff
- Bad fit: promises speed without process
- Better fit: explains review cycles, testing, and what happens when scope changes
Google’s DORA research has made a useful point here: reliable delivery matters as much as raw speed. I’d trust the person with a sane process over the person making heroic promises.
Common questions
What should I ask a website or app developer before hiring them? Ask what problem they think you’re solving, what they’re actually delivering, what happens after launch, who owns everything, and how they handle testing and security. If they can’t answer those clearly, keep looking.
Should I hire a developer or use off-the-shelf software? Use off-the-shelf software when your need is common and your business does not gain much from a custom workflow. Hire a developer when the gap between your real process and available tools is big enough to cost you time, errors, or missed work.
Is the cheapest developer quote the best deal? Usually not. The risk is not just low price — it’s vague scope and overconfidence. A cheap quote with weak discovery often becomes the expensive project later.
Who should own the website, app, or automation after it is built? You should own the important business assets: domain, hosting accounts, data, core access, and clearly defined rights to the finished work. If ownership is fuzzy before the project starts, it usually gets worse later.
If this is you, do this: don’t start by asking who can build it fastest. Start by asking who can help you avoid building the wrong thing. Then hire the developer who gives you a clear scope, plain-language trade-offs, and a believable plan for support after launch.
If you're staring at a messy internal workflow, repeat data entry, or a process that probably needs software instead of another spreadsheet, that's what I build — here's where to start with Custom Software Development.
Be the first to share your thoughts.