Who should you hire for your app?

How the assessment works

This assessment looks at three things:

1. Business evidence: Has the business earned more investment?
2. Engineering stakes: How much does the quality of the software matter now?
3. Working style: What kind of relationship do you actually want with the people building it?

You don’t need the highest possible score. You’re trying to figure out what your business needs right now.

Part 1: Has the business earned the investment?

I would answer this part before worrying about architecture, frameworks, technical debt, or whether your AI-generated code is “production ready.”

Bad code by itself is not a reason to spend a bunch of money.

1. Are people paying for this?

A free user and a customer are not the same signal.

If 2,000 people use something for free, you’ve definitely learned something. But strictly speaking, you’ve demonstrated that you can get 2,000 people to pay $0.

Don’t build a bill and mistake it for a business.

2. What does the problem cost your customer?

The more interesting question isn’t always, “Do people like this?”

It’s:

What happens if they don’t have it?

3. How frequently does the problem happen?

Frequency isn’t everything, especially when a rare event is extremely expensive. But frequent pain usually creates more opportunities for a product to become important.

4. How will customers find you?

Knowing 40 people in an industry isn’t necessarily distribution. They may be weak connections with zero interest in what you’re selling.

A smaller group of people who already come to you with the problem can be much stronger evidence.

5. Do you understand why customers would choose this over what they do today?

Your competitor isn’t always another app. It might be Excel, text messages, an employee doing something manually, an agency, or simply tolerating the problem.

Where your business lands on those five questions changes everything about what to build, how carefully to build it, and who should be building it.

Find out your business evidence score →

Part 2: How consequential has the software become?

This is a different question.

A business can be well validated while its software is still simple and low-risk.

It can also have terrifyingly complicated software while the business itself remains unproven.

Don’t confuse those two things.

1. Are real customers depending on it?

This is about operational dependence, not just whether people have signed up.

If the software disappeared for a day, would anyone’s work stop? Would they lose access to something they need? Would they have to fall back to spreadsheets, phone calls, or manual work?

The question is whether the software has become part of somebody else’s actual workflow.

2. What happens when the software fails?

Not every bug has the same consequence.

Sometimes failure means somebody refreshes the page and tries again. Sometimes it means a payment is duplicated, an appointment disappears, an order never reaches the right person, or a team cannot do its work.

You’re measuring the blast radius.

The more expensive, irreversible, or difficult to notice a failure becomes, the less appropriate it is to treat the software like a low-stakes prototype.

3. Does the software handle technically sensitive responsibilities?

Give yourself 1 point for each, up to 3:

• Money or payments
• Private or sensitive customer information
• Multiple companies, teams, permission levels, or complex access controls
• Important third-party integrations
• Automation that changes real-world business data
• High availability or performance expectations

The reason I care about things like multi-company access isn’t because they’re fancy.

It’s because a bug can stop being “the button doesn’t work” and become “one customer can see another customer’s data.”

That’s a different class of problem.

4. Has changing the software become unpredictable?

This is one of the most common failure patterns I see in AI-heavy development.

The AI fixes the bug in front of it. Then another behavior changes. You fix that. Something it fixed yesterday silently disappears.

Eventually you’re not really developing the product anymore. You’re negotiating with it.

That isn’t only a nontechnical-founder problem. In Stack Overflow’s 2025 Developer Survey, 66% of developers said one of their biggest frustrations with AI was getting solutions that were almost right, and 45% said debugging AI-generated code took more time. More developers distrusted AI output accuracy than trusted it.

AI is useful. I use it heavily.

But “AI wrote it” and “somebody is responsible for whether it’s correct” are different things.

5. How much of your own valuable time is engineering consuming?

This one matters more than people think.

The software doesn’t need to be literally impossible for you to maintain before hiring becomes rational.

It may simply be that you shouldn’t be the person spending Saturday debugging authentication anymore.

If customers rely on the software, failures carry real consequences, or the product is quietly eating your time, the stakes are no longer low—and the right setup changes with them.

Find out your engineering stakes score →

AI changed what “hire a developer” means

There used to be a somewhat useful shorthand:

One freelancer had one person’s capacity. An agency had several people’s capacity. A larger team could therefore take on more.

AI makes headcount a worse proxy for capability.

Upwork’s 2026 research found that the share of U.S. skilled knowledge workers freelancing increased from 28% to 38% in a year. In separate 2026 research, 77% of business leaders said AI was increasing their need for specialized fractional talent rather than traditional full-time roles. Demand for AI integration skills on Upwork grew 178% year over year.

One experienced engineer with good systems and AI can now execute considerably more than one person could a few years ago.

That’s good.

It also means a one-person “agency” tells you almost nothing about the person’s actual level of engineering experience.

AI lowers the barrier to doing the work, but it also lowers the barrier to selling ambitious work.

I don’t think the right response is to avoid people who use AI. Professional developers use AI too: 84% of Stack Overflow’s 2025 survey respondents were using or planning to use AI development tools.

The better question is:

Whose judgment is directing the AI?

Part 3: What kind of working relationship do you want?

There isn’t one hierarchy where freelancer < studio < agency < employee.

They’re different operating models.

Keep building it yourself

This is a good choice when:

• Business evidence is still weak.
• Engineering stakes are low.
• You’re learning valuable things by building.
• The product changes dramatically every week.
• You enjoy being hands-on.
• Professional development would consume money better spent proving the business.

This includes vibe coding.

I don’t think everybody needs to “graduate” from vibe coding.

AI has given founders an incredible ability to make things that previously required technical staff just to test.

Use that advantage.

The point where I become cautious is when experimental software becomes consequential software without the engineering underneath it changing.

There are already founders describing this exact transition: they successfully built products with AI, got pilots or paying users, then started looking for professional help because they weren’t confident in security, production maintenance, or long-term reliability.

Hire a freelancer or specialist

A freelancer is probably a good fit when:

• The work is relatively contained.
• You know what outcome you need.
• You want to manage the project directly.
• You need expertise in one particular area.
• You don’t need someone to own the entire technical direction of the product.

Examples might include an integration, performance problem, migration, security audit, or well-defined feature.

The freelancer doesn’t have to be cheap.

A very senior specialist may cost substantially more per hour than an agency employee and still be the more economical choice because you’re buying exactly the expertise you need.

Hire a senior product engineer or small studio

This can make sense when:

• The business has strong evidence behind it.
• The software is becoming consequential.
• You want to remain actively involved in shaping the product.
• You don’t want to personally own architecture, security, implementation quality, and technical tradeoffs.
• You want to talk directly to the person making important product and technical decisions.
• You need somebody who can help decide what to build, not merely implement instructions.

This is the model I personally like.

The business owner doesn’t disappear from the process.

They should remain extremely close to the part of the product that creates the business’s value.

But they don’t need to carry all of the engineering risk themselves.

Hire a traditional agency

An agency can be the right choice when:

• You want a managed team.
• You need several disciplines at once.
• You don’t want to personally coordinate developers, designers, QA, infrastructure, and delivery.
• The scope is substantial enough to benefit from parallel work.
• You prefer a more formal project-management process.
• You want to transfer a larger portion of execution responsibility.

Some people genuinely like this way of working.

If your speed is “here’s where the business needs to go; please organize the people required to get us there,” a traditional agency may be more comfortable than working intimately with one engineer.

Hire a fractional CTO or technical advisor

This makes sense when your biggest problem isn’t necessarily implementation.

You may instead need someone who can:

• Evaluate architecture
• Vet developers
• Review security and technical risk
• Decide what should be built versus bought
• Help create a technical roadmap
• Make hiring decisions
• Keep outside vendors accountable

If you already have people capable of doing the work but nobody senior enough to decide whether the work is correct, this can be a useful middle ground.

Hire an internal engineer or engineering team

Consider bringing engineering inside when:

• Software is a permanent core capability of the company.
• There is enough ongoing work to justify dedicated staff.
• Important technical knowledge needs to stay inside the organization.
• Product development is continuous rather than project-based.
• Engineering decisions are becoming company-level strategic decisions.

You do not necessarily need to wait until one product literally generates enough profit to cover an engineer’s salary.

The relevant question is whether the company benefits enough from having permanent technical capacity to justify the cost.

Quick decision table

How to evaluate a developer, studio, or agency in the AI era

I wouldn’t eliminate somebody because they use AI.

I also wouldn’t hire somebody because they tell you AI makes them 10x faster.

Ask how they think.

Ask who makes the technical decisions

If AI proposes the architecture, database structure, authentication system, deployment strategy, and security model, who decides whether those choices are appropriate?

You want an identifiable human answer.

Ask what they use AI for

“Everything” isn’t automatically impressive.

Neither is “nothing.”

An experienced developer should be able to explain where AI gives them leverage and where they apply more scrutiny.

The skepticism is normal. Stack Overflow found that experienced developers were among the least likely to highly trust AI output.

Ask how they verify work

Testing shouldn’t mean clicking through the happy path once.

Ask about automated tests, code review, security, permissions, failure states, monitoring, performance, and how they know one change didn’t break another part of the system.

Ask who owns everything

Your company should normally control its important assets:

• Domain
• Source-code repositories
• Hosting/cloud accounts
• Databases
• App-store accounts
• Analytics
• Payment accounts
• Third-party service accounts

Your developer needs access.

Access and ownership are not the same thing.

The anxiety around this is real. Founders moving from DIY development into professional help frequently ask how to avoid becoming dependent on one developer or losing control of technical assets.

Ask them about something they advised a client not to build

I like this question.

Software professionals are paid to build software, which creates a dangerous incentive: every problem can conveniently start looking like a software project.

I want somebody advising a business to be comfortable saying:

Don’t build that.

Or:

Buy this existing service instead.

Or:

You don’t know enough yet. Prototype it first.

Judgment is part of what you’re buying.

What about an app you already built with AI?

Don’t assume it needs to be rebuilt.

And don’t assume that because it works, it should become the foundation of the permanent product.

I’d look at the business and the code separately.

Your existing app may have already done something extremely valuable: it helped you figure out what you actually want.

You may have spent months refining workflows, business rules, terminology, edge cases, and customer behavior.

That knowledge is useful even if some or all of the implementation gets replaced.

When I inherit an AI-built product, I don’t start by assuming its code is trustworthy. I’d want to understand the business first, map the important workflows, review the existing system for useful business logic, and then make a deliberate decision about what deserves to survive.

Sometimes hardening the existing system is the right answer.

Sometimes starting clean is cheaper than repeatedly fixing a foundation that makes every future change harder.

The decision shouldn’t be ideological.

Take the assessment

Prefer to just answer? Pick the closest option for each question—the business and stakes reasoning is in Parts 1 and 2 above.

How the scoring works: each answer is worth 0 to 3 points, giving Part 1 a business-evidence score out of 9 and Part 2 an engineering-stakes score out of 9. Part 1 determines how much investment the business has earned, Part 2 determines how much engineering responsibility is warranted, and Part 3 determines what shape that help should take. The result is the best fit among the options your business has actually earned—plus an alignment percentage and a runner-up worth comparing.

Frequently asked questions