From First Call to Launch: My Freelance Development Project Process

My freelance development project process has seven stages: a short message, a first call, a paid fixed-price discovery phase for larger builds, a written proposal, the build itself in short iterations, testing and launch, and an agreed plan for support afterwards. The person you speak to on the first call is the person writing the code, and you own that code from day one.

Below is what happens at each stage, how long it typically takes, what you get out of it and what I need from you. For more detail on the build phases themselves, such as design, sprints and acceptance testing, see my overview of the software development process from idea to production.

The short answer: seven stages at a glance

Small, well-defined jobs, such as a single integration or one new feature in an existing Laravel app, usually skip discovery and go straight from call to proposal. Treat the durations as guides, not promises: an internal tool and a customer portal with payments and integrations are very different projects.

How much it matters to cut scope hard and get something real in front of users early. I wrote about that in from idea to SaaS: choices and priorities. The rest of this post walks through each stage in order.

Getting in touch and the first call

It starts with a short message. The contact form asks for project type, budget and timeline, and a few sentences about what you want built is plenty. You don't need a requirements document. I reply within one business day, either with a suggested time for a call or with an honest note that someone else would suit the job better.

The first call is a no-obligation conversation. I spend it on the business behind the project rather than the feature list, so expect questions like these:

• What problem should this solve, and for whom?
• How does the work get done today: spreadsheets, email, an old system?
• What's the one thing the first version has to do well?
• Who makes decisions on your side, and how much time do they have?
• What's the rough budget and timeline?

Budget is the question people most like to dodge. A rough range makes the call far more useful, because it decides whether to build from scratch, lean on an off-the-shelf tool for part of the job, or cut the first version down. My pricing page explains how I price work.

Working with a developer based in Denmark

Denmark runs on Central European Time, which is one hour ahead of the UK and six hours ahead of US Eastern Time for most of the year. For UK and EU businesses that means most of the working day overlaps. For East Coast teams, your mornings work well for calls, and much of the day-to-day back-and-forth happens in writing anyway. Being EU-based also means GDPR is part of the normal setup rather than an exotic extra.

The paid discovery phase, and why I insist on it

Before larger builds, I run a paid discovery phase at a fixed price. It can look like an extra step, so here's the reasoning. A quote for a whole system based on one call is a guess. Either the developer pads the price with a large buffer, or hidden requirements surface halfway through the build, when they're most expensive to deal with. Discovery moves the hard questions to the point where they're cheap to answer.

A typical discovery phase runs like this:

1. I walk through your workflows, users, data and existing systems with you, ideally with a few of the people who'll use the product.
2. The scope gets pinned down: what goes into version one and what can wait.
3. I write a technical plan covering the stack, hosting, integrations and what happens to existing data.
4. The riskiest parts of the project are named, each with a plan for handling it.
5. You get a price and a timeline for the build itself.

The output is a written brief you can make a decision on. If you choose not to continue, you still have a scope and a plan that another developer or agency can quote against. That's the point of it: discovery gives you a clean exit before the big money is spent.

Building an MVP? I've described how scoping and the first weeks work in my week-by-week MVP development process.

Proposal, contract and who owns what

Once discovery is done, you get a proposal for the build. It spells out what's included, what isn't, how invoicing works and how changes are handled. That last part matters. New ideas always appear once people start using something, and the contract should say what happens to them so neither of us gets a surprise.

Three things should be settled before any code is written:

• Ownership: you own the code from day one. In practice it lives in a repository you can access, so you're never waiting on me to hand it over.
• Accounts: domains, hosting and third-party services such as payments and email should be registered to your company, not to your developer. That makes switching suppliers painless if you ever need to.
• Personal data: if I need access to personal data, for example customer records in a database, I'm processing it on your behalf. Under Article 28 of the GDPR, that processing has to be governed by a contract, usually called a data processing agreement (DPA).

None of this is legal advice. If a lot is riding on the project, have a lawyer read the contract before you sign.

Building, testing and launching

How you follow progress

I build in short iterations, and each one ends with something you can click through and try. You catch misunderstandings after days, not months. Because you talk to me directly, a question about a button or a business rule gets settled in a short message instead of a status meeting. The tools I use for code, testing and communication are listed in my freelance developer toolkit.

The most useful thing you can do in this phase is answer quickly and test what I show you. Projects rarely stall because of the code. They stall when a decision sits in someone's inbox.

When the scope changes

Change requests are normal. I assess each one on its own: does it fit what was agreed, or does it need its own price? Sometimes the right answer is a swap, where a new feature replaces something planned and the budget holds. Sometimes it should wait until after launch. What matters is that the decision is made in the open, and that you know the impact on cost and timeline before work starts.

Launch

Before launch, you test the product with real workflows and, ideally, real data. I check the technical side: forms, payments, emails and integrations work, pages load fast, and backups run. Launch day is planned for a quiet moment, with time set aside for fixes in the first few days.

If the new site replaces an old one, the old URLs need redirects so you don't lose your Google rankings. You can see how I built SEO and speed in from the start in how I built simonij.com.

After launch: support and further development

A web app is never quite finished. Frameworks and packages need updates, someone has to watch errors and uptime, and once real users arrive, ideas for improvements follow. That's why the proposal already covers what happens after launch, usually in one of two ways:

• A maintenance agreement, where updates, monitoring and small fixes happen on a regular schedule.
• Ad hoc help, where you get in touch when something new needs building.

The first suits products your business depends on every day. The second can be enough for a simple website that rarely changes. My page on maintenance and ongoing development explains what an agreement covers.

My advice is to decide this before launch, not on the day something breaks. An app without an update plan quietly gets more expensive to fix, and you tend to find out when it's urgent.

When I'm not the right fit

I'd rather say no early than take on work I'm not the best choice for. Working with me is usually the wrong call if:

• you need branding, design, copywriting and development at the same time. An agency with several disciplines under one roof is often the better choice.
• you need a developer on the product every day for years. Hiring in-house is probably the right long-term move.
• the lowest hourly rate is your main criterion. You'll typically find lower rates on freelance marketplaces or with offshore teams.
• nobody on your side has time to answer questions and test along the way.
• you're a private individual. I work with businesses.

What I need from you is simple: one contact who can make decisions, replies within a couple of days when I ask something, and time to test what gets built. With that in place, the build itself is rarely the hard part.

Next steps: preparing for the first call

You'll get the most out of the first call if you've thought about the points below. You don't need answers to all of them. Working those out is exactly what the call and discovery are for.

When you're ready, tell me about your project on the contact page. I'll reply within one business day with a suggested time for a call, or an honest note if someone else would suit you better.

Frequently asked questions

How much does a discovery phase cost?+

It depends on the size of the project, but you get it as a fixed price before discovery starts, so you know exactly what you're paying for. As a rule of thumb, discovery should be a small share of the total build. In return, the price for everything after it becomes far more accurate, and you avoid paying for a large buffer in a quote built on guesswork.

What if my budget doesn't cover everything I want?+

Then version one gets cut down to solve the most important problem, and the rest moves to a later phase. Finding that line is one of the main jobs of discovery. It's usually better to launch something smaller and build on how people actually use it than to spread the budget thinly across every wish at once.

What happens if you get sick or become unavailable?+

You should be able to handle that risk whichever developer you choose. That's why you own the code from day one and have your own access to it, and why I recommend keeping domains and hosting in your company's name. Another developer can then take over if needed. Ask about it on the first call so you know exactly how your project is set up.

Can you take over a project another developer started?+

Yes. The process looks a little different, because it usually starts with a review of the existing code, hosting and documentation instead of a standard discovery phase. That tells you what state the app is in, what to fix first and whether it's worth building on what's there, before you commit to anything larger.