From Freelancer to Software Firm: What I Learned Running 50+ Projects

I started freelancing in 2016 with a laptop, a basic Upwork profile, and a solid knowledge of PHP and Laravel. Eight years and 50+ shipped projects later, I founded Zenpixl — a software firm with a small team, recurring clients, and a clear focus.

The path wasn't straight. Here's what I actually learned.

Lesson 1: Specialisation Pays More Than Breadth

My first few years, I took every project I could. WordPress sites, mobile apps, e-commerce stores, custom scripts, API integrations. The variety felt exciting. The income was inconsistent.

The shift happened when I started saying no to projects outside my core strength — Laravel backend development for SaaS and enterprise products. My close rate improved, my rates went up, and my projects got more interesting.

Clients don't pay premium rates for a generalist. They pay premium rates for someone who has obviously done their specific problem before.

The practical version of this: Pick two or three adjacent problem types you can do exceptionally well. Build a portfolio of those. Decline (or refer out) everything else.

Lesson 2: The Proposal Is Half the Job

Early on, I sent proposals that were essentially: "Hi, I can do this. Here's my rate. Let me know."

I started winning bigger contracts when I changed the proposal to demonstrate that I'd actually read and understood the brief — pointing out things the client hadn't mentioned but would encounter, asking one specific question that showed domain knowledge, and outlining how I'd approach the problem differently from the obvious path.

A well-written proposal signals the same thing good code signals: this person thinks before they act.

What works: Restate the problem in your own words first. Then your approach. Then timeline and rate. Keep it under 400 words. Ask one smart question.

Lesson 3: Scope Creep Kills Relationships

This is counterintuitive. You'd think doing extra work for a client strengthens the relationship. In my experience, it usually damages it.

When you silently absorb scope changes, a few things happen: you undercharge for actual work delivered, you feel resentful, the client doesn't realise they've overstepped (because you never told them), and when you finally push back, it feels arbitrary to them.

The healthier pattern: as soon as you notice scope expanding, name it clearly. "This is outside the original spec — happy to include it, here's the additional cost and time." Most decent clients respect this. It actually builds trust.

The practical version: Write a clear scope document before you start. Reference it when things expand.

Lesson 4: Fixed Price vs Hourly Is a Project Management Decision

I used to have opinions about which was "better." Now I see them as different tools.

Fixed price works when the scope is genuinely well-defined, the client can't move the goalposts easily, and the project is similar to something you've built before.

Hourly works when requirements will evolve, the client is hands-on and wants to participate in decisions, or the project is novel territory.

Most clients want fixed price because they want cost certainty. Most developers prefer hourly because they want to be paid for actual work. The solution is fixed price with a clearly defined scope and a change request process. Both parties get what they want.

Lesson 5: Client Quality Matters More Than Volume

The worst clients I ever had weren't necessarily difficult people — they were just wrong for my working style. Indecisive, unavailable for decisions, unclear about what success looked like, or expecting 2am responses because of time zone differences.

The best client relationships I have are built on mutual respect, clear communication, and a shared understanding of how we work together. Several of them have become multi-year relationships that account for significant recurring revenue.

Early in your career you take every client you can. As you build reputation, the most valuable thing you can do is get selective. The clients you decline are as important as the clients you take on.

Lesson 6: Build Systems, Not Just Outputs

For years, I delivered code and moved on. Each project was a fresh start: new folder structure, different conventions, rebuilt boilerplate.

The shift to running a firm required standardisation. We have a project kickoff template, a scope document structure, an onboarding checklist for new clients, a deployment checklist, a handover document template. These aren't bureaucracy — they're leverage.

When a new collaborator joins a project, they can read the kickoff document and understand the architecture, decisions made, and current state. When a client asks "what will handover look like?", we have a clear, consistent answer.

Systems compound. The effort to create a checklist once pays off every time it's used.

What I'd Tell Myself in 2016

Start specialising sooner. Write scope documents from day one. Charge more — the clients who push back hardest on price are often the most difficult to work with. Build systems from the beginning, not when you're overwhelmed.

And be patient with the relationship-building part. The clients who find you in year six via a referral from a happy client in year two are among the best you'll ever work with.

I'm still building Zenpixl and still learning. If you're a founder or technical leader looking for a software partner, I'd love to talk.