The first client who ever asked to see my portfolio watched me open my laptop, stare at a folder of Kaggle notebooks, and close it again. I talked for forty minutes about what I could build instead of what I had built. He signed the contract anyway.
That one had luck written all over it. The next one needed a method.
Three years ago I had no production machine learning work anywhere on my record. No client had paid me for a model. Every job description asked for three-plus years of production experience and a portfolio full of deployed systems, and I had neither. Today ML work is how I make a living as a freelancer, and founders message me instead of the other way around. The distance between those two states was never "more experience." It was a portfolio built from nothing — on purpose, in ninety days, with no client attached yet.
This is the playbook I used, and the one I now hand to every developer who asks the same question.
The Realization: Nobody Buys a Resume
My first real ML client was a logistics company in Dubai that ran three warehouses and booked storage capacity by gut feel. The founder's original request was simple: predict next-month demand per warehouse so they could stop over-booking storage they did not need and under-booking the months they did. I said yes before I knew exactly how I would do it.
I spent six weeks on it. The first version underpredicted demand by 40% in its first month, which meant my forecast confidently told them to free up space they actually needed. It was a soft, survivable miss — but it was a miss. I went back, added seasonality terms, lagged features from the previous three months, and stopped trusting a single model: I blended a gradient-boosted tree with a simple exponential smoother and kept the ensemble. The next month's forecast was within 6% of actuals. The client kept paying, then expanded the engagement to a second warehouse.
Here is what I learned from that first engagement: the founder did not hire my resume. He hired the fact that I showed up, asked sharp questions about his business, and took ownership of a problem he had been solving with a spreadsheet. My "portfolio" at that moment was a single Flask app on free hosting and a Medium post about it. He never asked for credentials. He was already past the "is this person qualified" filter, because I had shown him proof of effort in a language he understood.
The uncomfortable truth is that most developers fail to get ML clients not because they lack skills, but because they present qualifications instead of evidence. A buyer cannot verify "expert in deep learning." They can verify "this model takes my warehouse data and returns a number that helps me plan." Portfolios fail when they are résumés with screenshots attached.
So the entire playbook reduces to one sentence: produce evidence a non-technical buyer can verify in five minutes, and stop treating "portfolio" as a formal artifact that must be perfect before you start.
Step 1: Build One Proof Project That Solves a Business Problem
Not a Titanic survival notebook. Not another CIFAR classifier with a green dashboard. A project that maps to a business pain you can name out loud in one sentence: churn prediction for a SaaS, anomaly detection on inventory, lead scoring for a sales team, demand forecasting for a warehouse.
Pick a problem you can get real data for. In 2026 this is easier than ever: public datasets, synthetic generators, and — if you are clever — data you generate yourself by running your own small service and logging everything. I chose demand forecasting for a logistics operator because I could describe it in a single sentence to a founder. That sentence did more selling than any résumé bullet ever would have.
The rules I follow for the proof project:
- One project, not ten. A single deployed system beats a grid of abandoned notebooks. You can only maintain and evangelize one thing at a time.
- It must have a target, a metric, and a story. What number improved, and by how much? For mine it was forecast error dropping from 40% to 6%.
- You must be able to explain the trade-offs honestly. Where does it break, and what would you do differently at scale?
Do not let this step take longer than four to six weeks. The goal is not a finished product. It is a public, clickable, defensible artifact.
Here is the actual selection thinking, so you can copy the method: I wrote a page listing three candidate problems — churn prediction for a subscription tool, anomaly detection on warehouse inventory, demand forecasting for a logistics operator. For each, I asked three questions: can I get the data this month, can a founder understand the output in one glance, and can I defend the metric with a straight face? Demand forecasting won because the data was public and small, the output was a chart that needed zero explanation, and the metric — forecast error — was something a logistics founder already tracked in a spreadsheet. Churn prediction lost because I had no customer-level data I could legally use, and its output only means something when you add a lifetime-value model, which is too much explanation for a five-minute pitch.
Step 2: Make It Open Source and Publicly Inspectable
The strongest portfolio asset I have is a public repository with a real history: commits, failing tests, refactors, an honest README. Technical co-founders and the senior engineers who filter ML candidates will look at it. Non-technical recruiters rarely do, but the people who actually make hiring and buying decisions for ML work absolutely do.
Publicly visible work does two things:
- It is a permanent, time-stamped record that you have been shipping rather than just learning.
- It invites collaboration and questions, which turns your repo into a discovery surface. People find you through it, comment on it, and share it.
Do not polish it into a lie. One of the reasons my forecasting repo gets attention is the messy commit history — you can watch the model evolve, the 40% miss, the fix. Synthetic-clean repos are suspicious to exactly the people you want to impress.
The README is the front door of that repo: a one-paragraph problem statement, a screenshot or two, three commands to run it locally, and an honest "known limitations" section. That last section is the one that gets me messages — people open issues against it, and open issues are proof of life. A repo that reads like it was written for a job application reads like it was written for no one.
Step 3: Put a Live Demo Where Anyone Can Click It
This is the step that makes everything else click, and it is the cheapest one in the whole playbook. A portfolio that a client must clone and run locally is not a portfolio. It is homework.
I built a single-page demo: a form where you paste a CSV of weekly orders and get back a forecast chart with a confidence band. I deployed it in an afternoon on free hosting at misar.dev, because it cost nothing and the domain was real — not a myproject.netlify.app URL that screams "experiment." The client clicked the link, uploaded his own data, and watched a forecast appear. That one interaction did more to close the deal than every meeting I had booked.
Rules for the demo:
- One page, one job. Type in data, get an output. No login wall.
- It must work with the visitor's own data, not canned inputs.
- Show the uncertainty, not just the answer. A forecast with a confidence band reads as engineering maturity; a bare number reads as a sales pitch.
Step 4: Publish the Honest Write-Up
Here is the content play that changed everything: write the post-mortem, not the success story. My write-up about the model underprediction by 40% — and the exact changes I made — pulled in more qualified inbound than any "look at my accuracy" post I have published since.
Why it works is simple: honesty is the rarest commodity in ML marketing. Every other portfolio claims 99% accuracy on a toy problem. Yours admits the failure mode and shows the fix. Founders have been burned by ML salesmen; honesty is the differentiator, and it compounds because the post stays indexed and gets shared in exactly the communities where your next client hangs out.
Publish one genuine write-up per project. Put it on Medium, your own blog, LinkedIn, and the communities where practitioners and founders both appear. Then stop writing and spend the saved time on the next step.
Step 5: Go Where the Buyers Actually Are
A portfolio with no distribution is a trophy. The places that produced my first clients, in order of return on effort:
- Founder communities, not ML communities. Reddit founder subreddits, local startup meetups, founder Slack and Discord groups, X/Twitter threads where founders complain about manual processes. These are the people with the budget and the pain. ML forums are full of your competition, not your clients.
- The freelance marketplaces — as a channel, not a career. I used them early to land the first two paid jobs, each priced to win the work but structured so I could show the result publicly with permission. Marketplaces give you the first two data points; referrals and inbound give you everything after.
- Referrals from finished work. My third and fourth clients came entirely from the first two telling people: "this person shows up and fixes the thing."
A note on cold outreach: it works when the message leads with the problem, not the ask. "I saw you're doing X by hand; here is a demo you can click in thirty seconds" outperforms "I offer ML consulting" by a wide margin, because you are leading with evidence instead of a pitch.
A template that has worked for me, stripped to its skeleton: "I built a demand-forecast demo that takes a pasted CSV and returns a projection. It took a logistics operator from a 40% miss to 6%. If you want, I can point it at your numbers this week — it is twenty minutes on my side." Short, concrete, and it offers a test rather than a sales call. I have sent a version of this to founders who later became clients, and none of them asked for my portfolio on the way there.
Step 6: Price the Problem, Not the Algorithm
The last mistake is pricing. Early on I priced ML by the hour and left money on the table, because clients cannot judge how long a good model takes — so they assume it is fast and cheap. When I switched to pricing the outcome — the forecast that reduces their over-booking, the churn model that saves subscriptions — the number stopped looking like a cost and started looking like an investment.
My first client paid $350 a month for the forecasting work. My third charged a flat $2,400 for a churn model plus a 90-day iteration cycle, priced against the revenue the model was expected to protect, not the hours I guessed. Same skills, roughly seven times the price, and the client was happier because the framing matched what they were actually buying.
What I Would Skip
If you are short on time, here are the things I did that added nothing, and would cut today:
- Ten half-finished projects. I spent my first two months building four things and shipping none. One deployed system beats four screenshots every single time.
- Over-engineering the demo. My first version had a login wall, a dashboard, and an admin panel. Nobody used it. The final version was one input, one button, one chart — and that is what closed the deal.
- Chasing certificates. I have never once had a client ask for my certificates. I have had several ask for the live demo. Spend certificate money and certificate months on the demo instead.
- Posting only success stories. The underprediction write-up outperformed every win I published, because it is the one people can actually believe.
The Client-Acquisition Checklist
Before you send another proposal or update another résumé, run this list:
- [ ] One proof project, deployed, solving a named business problem
- [ ] Public repository with an honest history and a real README
- [ ] Live demo anyone can click in under a minute, on a real domain
- [ ] One honest post-mortem write-up published and linked from the demo
- [ ] Active presence in at least two founder-facing communities
- [ ] One finished paid job whose result you can show, with permission
- [ ] Pricing quoted as an outcome or a fixed project, never a vague hourly figure
The client who watched me close my laptop three years ago is now a reference. The portfolio that did not exist became three deployed systems, a public repo, and a demo link I paste into every conversation.
Start with step one today. Not ten projects. One, deployed, with an honest story. The rest of the playbook compounds from there — and the first client is closer than your résumé would have you believe.
*Gulshan Yad
Top comments (0)