My first freelance project was supposed to take six months

When I took on my first freelance project, I had about a year and a half of professional experience as a software developer. I had already built small full-stack applications to learn, but I felt one experience was missing from my path: delivering a complete product to a real client. I wanted to understand the business problem, negotiate directly with the client, make the technical decisions and take responsibility for the delivery. In other words, I wanted to find out what it was like to be my own boss.

The opportunity came up in 2021, through a referral from a former co-worker: a professional needed a digital platform to support their business activities. I knew it would be challenging and I was willing to take the risks to gain experience. What I didn't know yet was that building the application would be only part of the job.

The first trap: negotiating with only the experience in mind

My main motivation wasn't financial. I already had a job and saw freelancing as an opportunity to develop new skills, so I accepted a modest fee for the scope and the responsibilities involved, expecting to finish the project within six months. I don't think accepting a lower fee to gain experience was, on its own, a mistake. The problem was the way I handled the negotiation.

My commercial proposal was very simple: a generic description of the product, a fixed price, an estimate of hours and an expected delivery date. It didn't detail the requirements, each party's responsibilities or the acceptance criteria, and it had no procedure for scope changes either. On top of that, most of the payment depended on the final delivery. In practice, I took on most of the risk of a project whose needs weren't fully clear yet.

Today I understand that the commercial proposal is where both parties agree on the expectations and conditions that let them work with predictability. The price is only one part of it.

When the project started to take shape

I started development with the interface, building the main flows with mock data. I thought it would be easier to start with the front end, because that's where I had the most experience, and I wanted to validate how the solution worked before moving on to the integrations and the visual details. The catch was that some business rules depended on information the client had yet to send me. As the project moved forward, I realised that understanding the general idea of a product is different from having requirements defined well enough to implement it.

Besides understanding what the client wants to build, you need to define how the solution will work and which decisions are still to be made.

When the schedule no longer reflected reality

Over the course of the project, my professional and personal life changed a lot. I moved to another city, started a postgraduate course and had to split my time between new commitments and the development. The client also had little availability. As a result, the work lost momentum, and the project began to stretch far beyond the plan. I admit I should have handled these changes in a more organised way, reassessing the plan, recording the state of the project and renegotiating expectations.

When the circumstances behind a schedule change, the plan needs to be revised too.

When scope changes became a problem

One of the biggest challenges came from successive changes to the project's needs. Features that had already been built had to be modified or rebuilt to meet new business rules, and the complexity started to grow faster than I could manage. There were moments of real frustration: I would invest time in a feature and later have to revisit decisions I thought were already settled.

At some point, the architecture itself became part of the problem. I had to reorganise the code and adopt a simpler approach, with better-separated responsibilities, to be able to move forward. A well-structured architecture makes change easier, but it doesn't eliminate the cost of unstable requirements.

Scope changes are part of many projects. What needs to be agreed is how each one will be assessed, negotiated and incorporated into the project.

Delivery isn't necessarily the end

Finally, in August 2024, I completed the delivery of the application. After that, I made a few requested improvements and offered a support period to fix functional issues.

The experience also made me think about the difference between delivering an application that works and giving people the conditions to operate it on their own. Certain operations still depended on technical procedures, because extra administration features weren't part of the agreed solution.

In May 2026, I did the final handoff, organising the documentation and the information needed for another person to carry the project forward technically, and with that I formally ended my involvement. This last stage reinforced how important it is to set clear limits for the maintenance, support and evolution of software.

What would I do differently today?

After this experience, I came to see a commercial proposal as much more than a quote. If I were starting a freelance project today, I'd pay special attention to six points:

1. Understand the problem before pricing the solution. I'd try to understand the processes, goals and main constraints of the business.

2. Define what's in and out of scope. I'd document the planned features, the exclusions and the acceptance criteria.

3. Assign responsibilities. I'd make clear which information, access, materials and approvals depend on the client and what my obligations are.

4. Set delivery and payment milestones. I'd avoid concentrating most of the fee on the completion of the project.

5. Define a change process. I'd assess the impact on timeline and cost before taking on new requirements.

6. Separate delivery, warranty, support and maintenance. I'd make clear what's included in the engagement and what requires a new agreement.

These practices don't eliminate risk, but they make expectations clearer and the commercial relationship more balanced.

How my commercial proposal evolved

Recently, I turned some of these lessons into a commercial proposal template for developing an MVP. It's teaching material and entirely fictional: the client, values and timelines are made up, and the document is annotated, with notes explaining why each clause exists and a final page with a checklist for adapting it to your project. It covers scope, exclusions, responsibilities, milestones and acceptance criteria, payment, scope changes, warranty, support and handoff.

Open larger view

The eight pages of the template. The educational notes comment on the clauses, and the last page has the adaptation checklist and the risks the template aims to prevent.

• Open the template as a PDF (8 pages)
• Download the editable version (DOCX)

Use the template as a starting point for your own proposal, not as a ready-made contract. Every project has its own particularities and may call for different technical, commercial and legal agreements, and the document itself recommends a legal review when there are material commitments or sensitive data.

A first freelance project demands concessions, but they need limits

If you're thinking about taking on your first freelance project, you may need to make concessions, such as offering a more competitive price, picking a smaller project or spending more time discovering requirements. Those decisions can make sense when they're part of a conscious strategy for learning and professional positioning. But making concessions doesn't mean accepting unlimited responsibilities.

A lower price doesn't require an undefined scope, and wanting to gain experience doesn't excuse you from negotiating fair terms.

Protecting your interests isn't acting against the client, either. A well-structured negotiation benefits whoever is hiring, because it reduces ambiguity and makes the project easier to follow.

Final thoughts

My first freelance project wasn't a particularly successful commercial experience. The financial return was modest for the effort and responsibility I took on, the project dragged on far longer than planned and I made mistakes that I can now see much more clearly. Even so, I faced problems that go beyond implementing features, such as negotiation, planning, communication, changing requirements, architectural decisions and handing over responsibilities. And I learned that mastering a technology doesn't mean being prepared to run a software project.

If I could leave one recommendation for those just starting out, it would be this:

Don't be afraid to make concessions to gain experience. But try to understand exactly what you're giving up, what risks you're taking on and where your limits are.

Learning to negotiate is also part of becoming a more well-rounded software engineer.