What Kind of Developer Do I Need? A Decision Guide by Project Type

The kind of developer you need depends on three things: what you're building, what you can spend, and when it has to be live. For most small and mid-sized companies the answer is one of four: a WordPress, Webflow or Shopify developer for websites and online stores, a no-code builder to test an idea cheaply, a full-stack developer for custom web apps and internal tools, or a team when a lot has to ship fast.

I'm a freelance full-stack developer based in Denmark, so read this with that bias in mind. I've built the guide to point away from me whenever that's the right answer.

The short answer: which developer for which project

Find the row closest to your project. The "Usual answer" column is the default, and the last two columns show when to go a different way.

Treat the table as a rule of thumb. The four steps below let you test your own project against it. If you'd rather start with what each role actually does, my rundown of the main types of developers covers that first.

Step 1: What are you building?

Start with the job, not the job title. Find the hardest part of the project, because that almost always decides which developer you need.

Most projects fall into one of five groups:

1. Content and sales: marketing websites, landing pages and online stores. The hard part is content, design and getting visitors to act, not the code. A WordPress, Webflow or Shopify developer usually delivers faster and cheaper than someone building from scratch. I've covered where that stops working in when a WordPress developer is the right hire.
2. Workflows and data: customer portals, booking systems, internal tools and integrations. The hard part is business rules, permissions and data that has to stay consistent across systems. A full-stack or backend developer is the usual answer.
3. Products: an MVP (the smallest version you can put in front of real users) or a SaaS you plan to sell. The hard part is building little enough to learn fast while leaving room to keep building. Pick someone who has taken a product from idea to paying users, not only worked through client tickets.
4. Mobile: apps that live in the App Store and Google Play and use the camera, GPS or push notifications. That needs a mobile developer, though plenty of ideas work fine as a web app that runs well on a phone.
5. Existing code: if someone has to take over or extend a system, the stack is already chosen. Hire someone who knows it, so you don't pay for them to learn it.

If your project fits more than one group, go by the part that's hardest or most expensive to get wrong. An online store with customer-specific pricing and an ERP integration is really a custom system with a shop on top.

Step 2: What's your budget?

Budget rarely changes the kind of developer you need. It changes how much can be built, and whether to build anything custom yet. A common mistake is to answer a small budget with a cheaper developer instead of a smaller project.

These are rough market estimates for an experienced developer in Western or Northern Europe and no substitute for a quote. Lancebase puts freelance full-stack developers in Western Europe at around €75-120 an hour, so €20,000 buys roughly 170-270 hours of work. Ranges for each project type are in my guide to software development cost. Many cost figures online are USD quotes from US agencies or offshore vendors, so treat those as a different market.

If your budget sits below what the project needs, you have three honest options: shrink the first version, start with no-code or an off-the-shelf tool, or wait until the money is there. A no-code prototype can show whether anyone wants the product before you pay for code. I've written about where no-code tools hit their limits.

Launch isn't the last invoice either. Software needs updates, monitoring and fixes, so budget for running costs every year.

Step 3: When does it need to be live?

Your timeline decides how many people you need, not which kind. One developer can build a lot, but only at one pace.

Without a hard deadline, one developer is often both the cheapest and the fastest option overall. There are no handoffs between frontend and backend, no status meetings to keep five people in sync, and you talk directly to the person writing the code. I've looked at where that model runs out in when one full-stack developer is enough.

With a date that can't move, such as a trade show, a funding round or a seasonal peak, work backwards. My rule of thumb: take the realistic hours from an estimate and divide by about 120 hours a month (what one person can manage full time). If that lands after your deadline, you need more people or a smaller first version. Also ask how many hours a week the developer can actually give you, since many freelancers work with several clients at once.

More developers don't make a project proportionally faster. Every extra person adds coordination, so two developers rarely ship twice as much as one. If you only have a few weeks, an off-the-shelf platform or no-code is often the only realistic answer.

Step 4: Who looks after it, and where should they be?

The last step is about the working model: freelancer, agency or in-house hire. What happens after launch decides it more than anything else.

A website that rarely changes can be built by a freelancer or a small agency, with an agreement for updates afterwards. A system that becomes business-critical needs someone who still knows the code a year from now and can fix problems quickly. That can be a freelancer on a maintenance agreement or an agency. I've compared the two in freelancer vs agency: an honest look at cost and risk.

If the product is your whole business and needs daily development for years, an in-house developer or team is usually right in the long run. If it needs someone on call around the clock, you need a team, because one person can't promise that.

Location matters more than most buyers expect. A developer on Central European Time shares almost the whole working day with the UK and the rest of the EU, and overlaps with the morning on the US East Coast. And if you serve users in the EU, GDPR applies even when your company is based outside the EU, so ask early where data and backups will be hosted. This isn't legal advice, so check the details with a lawyer.

Whatever you choose, keep the code in your own repository and the hosting and domain accounts in your name. With me, you own the code from day one, which means you can switch developers if the relationship doesn't work out.

Three worked examples

Here are three typical situations and where the guide lands. The examples are made up for illustration and aren't based on client work.

An architecture studio that wants a new website

Project type: content and sales. Budget: around €6,000. Deadline: ten weeks. The answer is a Webflow or WordPress developer working from a good template. Hiring a full-stack developer like me means paying for skills the job doesn't need.

A wholesaler that wants an ordering portal for trade customers

Project type: workflows and data, with customer-specific pricing and an ERP integration. Budget: around €35,000. Deadline: flexible, ideally live within six months. The answer is a full-stack developer, starting with a short discovery phase to pin down the integration. Shopify with a stack of apps is tempting, but the pricing rules will end up fighting the platform.

A founder with a SaaS idea and €10,000

Project type: product. Budget: below what a coded MVP usually costs. Deadline: wants to test within two months. The answer is a no-code prototype that tests whether anyone will pay, then code once there are paying customers. The alternative is a very narrow coded MVP with one core workflow and nothing else.

When the answer is no developer (yet)

Sometimes the honest answer is not to hire anyone yet. That usually applies in four situations:

• An off-the-shelf tool for booking, CRM or invoicing covers most of what you need. A subscription plus a small change to how you work is almost always cheaper.
• You can't yet describe who will use it and what they need to get done. Write that down first, or you're paying a developer to guess.
• The problem is a process, not a system. Software makes an unclear workflow faster, not better.
• You have money to build it but not to run it afterwards.

Next steps: from decision to first conversation

Once you've worked through the four steps, you know which kind of developer to contact. Here's how to move forward:

1. Write half a page about the project: who will use it, what it needs to do, and which systems it has to connect to.
2. Note a budget range and a deadline, even if both are uncertain.
3. Use the table at the top to find the kind of developer to approach.
4. Talk to two or three developers of that kind, and ask about similar projects that are still running.
5. For larger projects, start with a paid fixed-price discovery phase, so scope and price are agreed before anything is built.

If the guide points to a full-stack developer for a custom web app, customer portal or SaaS, you can see how I price projects. If it points to a different kind of developer, that's a useful answer too.

Frequently asked questions

Should I choose the tech stack before I choose a developer?+

Usually not. Describe the problem and let the developer suggest a stack and explain why it fits. The exceptions are when you already have a system built on a particular stack, or when your own team will take over the code later. In those cases the developer needs to know that specific stack well.

How can I tell if a developer is senior enough without a technical background?+

Ask about similar projects that are still running after launch, and how they'd approach yours. A senior developer asks more questions about your business than about the technology, names the biggest risks without being prompted, and explains choices in plain language. A short call with a previous client tells you more than a list of frameworks.

Is it cheaper to hire an offshore developer?+

The hourly rate is often lower, but the total cost isn't always. Time zone gaps, slower feedback loops and rework can eat into the savings, especially when the requirements aren't fully written down. Offshore teams tend to work best on well-defined tasks with a technical lead on your side who can review the work.

What if I've already hired the wrong kind of developer?+

Stop early rather than hoping it sorts itself out. Make sure you have access to the code and every account, then ask another developer to review what's been built. Part of it can often be reused. The expensive mistake is carrying on for months with a setup that doesn't fit the job.