I Started Coding at 14. Here's What a Decade of Shipping Taught Me.
At 14 I charged EUR 200 for a WordPress site that took me 3 weeks. At 24 I charge EUR 60k for a SaaS product that ships in 6 months. The code got better. The lessons had nothing to do with code.

EUR 200. That's what I charged for my first client project at 14 years old. A WordPress site for a local restaurant. It took me 3 weeks, which means I earned roughly EUR 1.40/hour. The site had a rotating image carousel, a menu page, and a contact form that didn't work for the first two weeks.
A decade later, I co-run RalphNex with Dash, shipping SaaS products for EUR 60k. The technical skills improved, obviously. But the lessons that actually built the business had almost nothing to do with code. They were about people, money, scope, and knowing when to say no.
Key Takeaways > - Technical skill is table stakes. What separates successful engineers from struggling ones is everything around the code: communication, scoping, saying no. > - Freelancing teaches you every part of a business in compressed time. I learned sales, project management, accounting, and client management by necessity. > - The biggest shift from freelancer to agency was moving from selling time to selling outcomes.
Phase 1: The Freelancing Years (14-18)
I built my first real website at 14. Not from a tutorial - for a paying client. My uncle's friend needed a restaurant website. My uncle said "my nephew does computers." That was the entire sales process.
The WordPress site took 3 weeks because I was learning PHP while building it. The client was patient because they were paying EUR 200 and had zero expectations. I was ecstatic because EUR 200 was an absurd amount of money to a 14-year-old.
Lesson 1: Start before you're ready. I didn't know PHP. I didn't know WordPress. I didn't know how to set up hosting. I figured out each problem as I hit it. Every project for the next 4 years followed this pattern: accept the work, then figure out how to do it. The deadline was more effective than any tutorial.
Between 14 and 18, I built around 40 websites. Mostly WordPress. Mostly for small businesses in my network. The prices crept up: EUR 200, then EUR 500, then EUR 1,000, then EUR 2,000. Each price increase felt terrifying. Each time, the client said yes without flinching. I was consistently undercharging.
Lesson 2: Price is a story you tell yourself. When I charged EUR 500, I thought EUR 1,000 was impossible. When I charged EUR 1,000, EUR 2,000 seemed greedy. The client never once told me I was too expensive. The resistance was entirely in my head. I spent 4 years leaving money on the table because of a narrative I made up about what I was worth.
Phase 2: Getting Serious (18-21)
At 18, I stopped building WordPress sites and learned React. This was the hardest transition I've made. Going from WordPress (drag, drop, install plugin) to React (write everything from scratch, understand state management, deal with build tools) felt like starting over.
It took 6 months before I could build anything useful in React. During those 6 months, I turned down client work because I wasn't confident enough to deliver in a stack I was still learning. That was the wrong call.
Lesson 3: Never stop taking projects to learn. Those 6 months of "learning first, earning later" cost me roughly EUR 15k in lost freelancing income. I should have taken projects and learned on the job, like I did at 14. Formal learning has its place, but it doesn't replace the urgency of a client deadline.
By 20, I was building full-stack applications. React frontends, Node.js backends, PostgreSQL databases. The projects got bigger: EUR 5k, EUR 8k, EUR 12k. And with bigger projects came bigger problems.
My first EUR 12k project nearly broke me. A client wanted a booking platform. I scoped it as "3 months of work." No detailed specification. No user stories. No sprint plan. Just "booking platform, EUR 12k, 3 months."
It took 5 months. I ate the extra 2 months because it was fixed-price with no scope definition. The client kept adding features ("Can we also add a review system?") and I kept saying yes because I didn't know I could say no.
Lesson 4: Scope is the single most important part of a project. Not design. Not technology. Not the team. Scope. Every project that went badly in my career went badly because scope wasn't defined clearly enough. This is why we're obsessive about scope definition at RalphNex. I learned the lesson the expensive way.
Phase 3: The Collaborations (21-23)
I met Dash when we were both freelancing on overlapping projects. He was doing design and frontend. I was doing backend and infrastructure. We kept getting referred to the same clients and decided to just work together.
The first project we did together was a mobile app for a food delivery startup. We charged EUR 15k total (split EUR 7.5k each). It was the smoothest project either of us had done. Not because the project was easy, but because having a second person meant we could specialize.
I stopped worrying about design decisions. Dash stopped worrying about database architecture. Each of us operated in our zone of competence instead of stretching across every skill.
Lesson 5: Two specialists beat one generalist. I spent 7 years being a full-stack generalist who did everything okay and nothing great. In 2 months of working with Dash, the quality of our output doubled. Collaboration isn't about dividing work. It's about multiplying capability.
We did 6 projects together over 2 years before formalizing RalphNex. The total revenue was around EUR 120k split between us. Not life-changing, but enough to validate that the partnership worked under stress.
The worst project during this period was a client who went silent for 3 months mid-project, then reappeared demanding we finish immediately. We had moved on to other work. The project context was gone. We spent 2 weeks re-learning the codebase before we could make progress.
Lesson 6: Context evaporates. Documentation preserves it. This experience is directly why we practice harness engineering. If we had documented architecture decisions and setup procedures during the build, those 2 weeks of re-learning would have been 2 days. We now write docs as we code, not because it's noble, but because we got burned by not doing it.
Phase 4: Building the Agency (23-Present)
Formalizing RalphNex was less dramatic than it sounds. We registered the company in Estonia, put up a website, and started charging agency rates instead of freelancer rates.
The first real agency project was Pushary. A push notification SaaS, built from zero to production in 30 days. We charged EUR 55k (our prices have increased slightly since). It was the project that proved the model: two senior engineers, fixed scope, aggressive timeline, complete documentation handoff.
Lesson 7: Selling outcomes is fundamentally different from selling time. As freelancers, we sold hours. "This will take 200 hours at EUR 75/hour." As an agency, we sell products. "This is a production-ready SaaS for EUR 60k." The hourly math might be similar, but the client perception is completely different. They're not buying our time. They're buying a finished product with a guaranteed scope and price.
The shift to outcome-based pricing also changed how we worked. When you sell hours, there's no incentive to be fast. When you sell a fixed-scope outcome, every hour of efficiency increases your margin. We became relentlessly focused on eliminating waste: unnecessary meetings, over-engineering, scope creep.
Here's the contrarian take from a decade of shipping: the most important skill for a software engineer isn't coding. It's saying no. No to features that don't belong in v1. No to clients who won't define scope. No to technologies chosen for hype instead of fit. No to projects that are obviously underscoped for the budget.
Every bad project I've had could have been prevented by saying no to something. The EUR 12k booking platform? No to undefined scope. The disappearing client? No to starting without a milestone payment schedule. The 5-month timeline on a 3-month project? No to scope additions without price adjustments.
What I'd Tell My 14-Year-Old Self
Charge more, sooner. You'll spend years undercharging because you're comparing yourself to people with 20 years of experience. You're not competing with them. You're competing with people who charge the same as you and deliver worse. Raise your prices until someone says no, then stay at that price.
Write everything down. Every decision. Every architecture choice. Every client conversation. Your memory isn't as good as you think. The documentation habit you build now saves you thousands of hours later.
Learn to scope before you learn new frameworks. React, Vue, Svelte - they change every 3 years. Scoping skills are permanent. A perfectly scoped project in an outdated framework ships faster than a terribly scoped project in the latest stack.
Find your Dash. A partner who complements your skills turns a freelancing career into a business. You can't scale yourself. You can scale a team.
Projects > tutorials. Every real project I took taught me more in a week than a month of tutorials. The tutorials taught me syntax. The projects taught me judgment.
The Numbers
Since I'm a fan of specifics, here's the decade in numbers:
- Projects completed: ~80 (freelance) + 12 (agency) - Revenue (freelancing years): ~EUR 180k over 9 years - Revenue (agency, 2+ years): significantly more per year - Projects that went over budget: 4 (all in the freelancing years, all due to poor scoping) - Clients who came back for a second project: 60%+ - Average project size growth: EUR 200 (age 14) to EUR 60,000 (age 24). A 300x increase.
The 300x increase in project value came from 3 things: better skills (maybe 3x), better scoping (maybe 5x), and better positioning (the rest). Positioning - being known as "the agency that ships SaaS products in 6 months with full docs" - did more for our pricing than any technical improvement.
Frequently Asked Questions
How did you get your first clients as a teenager?
Word of mouth through family and their network. My uncle connected me to 3 clients. Those clients referred 5 more. By 16, I had a small reputation in my local community as "the kid who builds websites." I never ran ads or did cold outreach until I was 20. For early career freelancers, your existing network is underrated. Everyone knows someone who needs a website.
When did you start making a full-time income from coding?
At 19, I was earning roughly EUR 2,500/month consistently from freelancing. Not comfortable by Western European standards, but enough to live on. By 21, it was EUR 4,000-5,000/month. The jump to agency income was significant, but even as a freelancer, I was making a reasonable living by my early 20s.
What's the biggest mistake you made in your career?
Not defining scope properly on that EUR 12k booking platform at age 20. I lost 2 months of unpaid work and nearly burned out. It taught me the most important lesson of my career: scope first, code second. Every process at RalphNex exists because of a mistake I made as a freelancer.
What programming languages do you use now vs when you started?
Started with PHP and WordPress. Moved to JavaScript (React, Node.js) at 18. Now we primarily use TypeScript, Next.js, React Native, PostgreSQL, and Python for backend services. The stack changes every few years, but the fundamentals - data structures, API design, database modeling - have been constant.
*Want to work with a team that's been shipping since before we could drive? Book a 30-minute call and we'll show you how a decade of experience translates to faster, more reliable delivery. Or learn more about our story.*
Notes on building fast.
One short email a month from the RalphNex team. Projects we shipped, ideas we tested, and what worked.
No spam. Unsubscribe anytime.

Aadil Ghani
Founder & CEO
Co-founder and managing director of RalphNex. Started coding at 14. Writes about building fast and the projects we ship.
More from the RalphNex Journal

How We Set Up CI/CD for Every Client Project
Every project we ship gets the same CI/CD pipeline. It takes 4 hours to set up and saves 200+ hours over the project lifetime.

SaaS Development for Edtech: Building for Schools and Students
Schools buy software in June, onboard in August, and complain in September. Your edtech product needs to survive all three.
