Part Three: The engine · Chapter 9
Proof, not portfolio.
Stop presenting projects as lists of technologies. Show whose problem you solved, what changed and what happened when the work became difficult.
Part Three: The engine
The route you picked decides who pays you. This part decides whether anybody does.
The portfolio problem
Your projects may demonstrate code without demonstrating delivery.
Your portfolio probably contains a weather app, a to-do list, an e-commerce clone and a personal site.
They are clean, responsive and deployed. They demonstrate that you can code.
They persuade nobody, and there is one reason for that: everybody can tell that you followed a tutorial.
That is not necessarily because the code is bad. It is because the project contained no client, no external constraint and no consequence.
The buyer is asking what happens when the work becomes difficult.
They are not primarily asking whether you can write code. They generally assume that you can.
They want to know whether you can work through incomplete requirements, awkward users, unexpected technical behaviour and a deadline that still exists after something goes wrong.
A tutorial project is completely silent on that question.
What actually counts
Not all portfolio evidence carries the same weight.
01
Paid work
Paid work sits at the top. Somebody with money assessed the risk, trusted you and received the promised result.
02
Unpaid work with real users and real stakes
A booking system that your local football club actually uses. A stock spreadsheet replaced for a family friend’s shop.
There were deadlines, complaints and people depending on the result. This evidence is easier to obtain than paid work when you have nothing—and almost as persuasive.
03
A live product with users
Even fifty real users prove that you shipped something, handled feedback and kept it working after launch.
04
A substantial contribution
A merged pull request on a project people use or documentation that somebody adopted demonstrates useful participation in work larger than your own practice project.
05
A tutorial project
A tutorial project is worth close to nothing as evidence. Not negative—just unable to answer the buyer’s real question.
If you have nothing on that list
The fastest fix is not another course.
Find one real person with one real problem and solve it for free this month.
Make the conditions explicit: they must use what you build, give you honest feedback and tell you what is wrong with it.
The objective is not to fill your portfolio with unpaid work. It is to move from an invented project with no consequences to a real delivery with users, constraints and evidence.
How to write it up
Use four sentences, not a technology list.
Most developers describe a project by listing its materials: React, Node, Tailwind, deployed on Vercel.
That tells a buyer what you used. It does not tell them what work you completed, why it mattered or whether you could handle difficulty.
01
Whose problem was it?
Name the real person or organisation and explain what the problem was costing them.
“A driving instructor was losing bookings because learners rang during lessons and reached voicemail.”
02
What did you do?
Describe the work plainly, using language a non-developer can understand.
03
What changed?
Use a number when you have one. If you do not, explain what stopped being a problem after the work was delivered.
04
What was difficult?
Explain what went wrong, what you discovered and how you handled it.
“The payment provider’s sandbox behaved differently from live, and I discovered this two days before launch.”
The fourth sentence is the whole thing.
Every technical person reading it knows that you were actually there.
A tutorial follower can repeat the happy path. They cannot describe the unexpected behaviour, difficult decision or real-world constraint that only appeared because somebody depended on the result.
The mistake I see most often
People hide their best evidence.
They build something for a family member’s business, get it working and then leave it out of the portfolio because it was not “a proper client” or the design is not impressive enough.
The unglamorous real thing beats the beautiful fake thing every single time.
Put it at the top and write the four sentences.
Continue reading
Next: Scoping and pricing your first jobs
Chapter 10 covers the professional work between a client’s first request and the price you eventually put in writing.