
The Engineering That Keeps Dhaka Metro Moving
An in-depth technical analysis of Dhaka Metro Line 6 engineering: from 1500V DC overhead catenary power and regenerative braking to real-time CBTC signalling and SCADA systems.

12 min read
Quick Summary
The fastest way to vet a developer’s portfolio when you can’t read a line of code is to stop judging screenshots and start checking three things: whether the projects are live and actually work, whether the work is recent, and whether real clients will vouch for it on a call. None of that requires technical knowledge — it just requires knowing which questions a polished screenshot can’t answer, and which shortcuts a portfolio can’t fake.
This guide is for founders and hiring managers who don’t code but are about to make a real hiring decision — whether that’s a solo freelancer, a two-person dev shop, or a full agency. Every step below is something you can do yourself in an afternoon, without needing to understand a single technical term you haven’t already heard from the developer’s own mouth.
Most non-technical founders get their first technical hire wrong. A widely cited survey by CoffeeSpace found that 68% of founders admitted to making a costly mistake on their first technical hire, and only 22% had used any kind of structured vetting process — most were hiring on gut feel and a friendly video call. That gamble is expensive: U.S. Department of Labor estimates put the cost of a bad hire at a floor of 30% of first-year salary, while SHRM data widely cited in 2026 hiring reports puts the real range at 50% to 200% of annual salary, and CareerBuilder figures suggest a bad hire can cost anywhere from $17,000 for a junior role to $240,000 for a specialist.
A portfolio is the first — and often only — piece of evidence you get before making that decision. Learning to vet a developer’s portfolio properly is one of the highest-leverage 30 minutes you’ll spend before signing anything, and it costs nothing but a bit of structure.
Live, Working Products — Not Just Mockups
A portfolio full of Figma files, Dribbble shots, or screenshots with no working link attached tells you almost nothing about whether the person can ship. Ask for links you can actually click and use — a live website, a downloadable app, or a demo account. If every project in the portfolio is a static image, that’s already useful information.
A portfolio of apps built years ago says very little about a developer’s capability today, since tooling, frameworks, and design standards shift quickly. Look specifically for shipped work from the last 12–18 months — anything older should be treated as background, not current evidence.
A beautiful landing page and a functioning, multi-user product with real data are very different achievements. Look for at least one project in the portfolio that’s genuinely comparable in complexity to what you’re about to build — not just visually similar.
It’s worth remembering that visual polish and engineering difficulty don’t always correlate. A gorgeous marketing site can be built by a talented designer with very little backend skill, while a plain-looking internal dashboard might involve real-time data syncing, permissions, and integrations that are far harder to get right. Ask what’s happening behind the screen you’re looking at, not just how it looks.

One of the most common ways portfolios mislead non-technical founders isn’t outright lying — it’s inflated credit. A junior developer who touched one screen of a large app may list the entire product as “my work.” A vendor may show a client’s finished app without clarifying they built only the backend, or vice versa. This is common enough in mobile development specifically that industry commentary puts a meaningful share of failed early hires down to exactly this kind of portfolio padding, where a founder discovers months in that the person’s actual role was far smaller than implied.
The fix isn’t suspicion for its own sake — it’s specificity. Ask exactly what the person built, who else was on the team, and what their individual responsibility was on each listed project. A confident, precise answer is a good sign; vagueness or irritation at the question is not.
Once you’ve got a shortlist, vetting a developer’s portfolio is really a five-step process, and none of the steps require you to open an IDE.
Instead of reading the portfolio alone, ask the developer to screen-share a project and explain what it does and why they made the choices they made. Strong developers explain trade-offs in plain English; weaker ones retreat into jargon the moment you ask a follow-up question. Clarity here is a direct preview of what working with them day to day will feel like.
If a developer has a public GitHub profile, you can pull useful signal without understanding a single function. Check whether they commit regularly (not just one burst of activity three years ago), whether their repositories have a written README explaining what the project does, and whether they’ve closed issues or just abandoned projects halfway. Consistency and documentation habits say more about professionalism than the code itself ever will to a non-technical reader.
For app developers specifically, check the App Store or Google Play listing directly and confirm the developer or studio name matches who you’re talking to. Portfolio padding — presenting someone else’s shipped app as your own work, or claiming a senior role on a project you were peripheral to — is common enough that this single check catches a meaningful share of exaggerated portfolios.
Most founders either skip references entirely or ask questions so broad they’re useless. “Were you happy with their work?” will almost always get a yes. Ask instead: was the final cost within 20% of the original estimate; how did they handle a major problem or setback mid-project; did they explain technical decisions in plain English; and would you hire them again for a larger, more complex project. Ask to speak to the last three clients, not hand-picked favorites — framing it that way makes candid answers far more likely.
Treat hesitation here as data. A developer with a genuinely strong track record is usually happy to connect you with recent clients quickly, because it’s the easiest sales tool they have. Slow, reluctant, or evasive responses to a reference request are worth weighing as heavily as anything in the portfolio itself.
Before committing to a full engagement, pay for one to two weeks of well-scoped, real work at the developer’s normal rate. You’ll learn more from watching someone actually work — how they scope a task, ask questions, and report progress — than from any interview or portfolio review. Some people interview beautifully and produce mediocre work; others interview awkwardly and turn out excellent. A trial project reveals the difference reliably.
Keep the trial task genuinely small and clearly bounded — a single, well-defined feature rather than an open-ended chunk of the real project. The goal isn’t to get free work out of the process; it’s to observe how the person handles a contained assignment before you hand them something bigger.
You don’t need technical vocabulary to ask questions that expose real skill. Try these, verbatim:
A handful of warning signs come up again and again once you actually start to vet a developer’s portfolio closely, and any one of them is worth pausing on before you sign.
If you have access to one, a trusted technical advisor — a friend who codes, a fractional CTO, or an engineer you meet through a startup community — can vet a developer’s portfolio and a candidate’s answers far faster and more reliably than you can alone. This isn’t a sign of weakness; it’s simply using the right tool. If no one is available, structured online assessments like HackerRank give you a semi-objective skill signal without requiring you to judge code yourself. Some founders even hire two part-time developers instead of one full-time hire specifically so each can check the other’s work, which keeps both honest without needing an in-house technical lead at all.
If building a vetting process from scratch feels like too much, several platforms do a meaningful chunk of the screening for you before a candidate ever reaches your shortlist. Toptal pre-screens for senior talent and is priced accordingly — often in the $2,000–$3,200-per-week range for a dedicated developer — but the consistency of quality is part of what you’re paying for. Turing and Arc.dev offer similar pre-vetted talent pools at more competitive pricing, useful if Toptal’s rate is out of reach. For agencies rather than individual freelancers, directories like Clutch and GoodFirms aggregate verified client reviews, which function as a lighter-weight version of the reference-call step above, done at scale by other buyers before you.
None of these platforms remove the need to vet a developer’s portfolio yourself — they simply raise the floor of who you’re choosing from. Treat a Toptal or Clutch listing as a strong starting filter, not a substitute for asking your own reference-call and trial-task questions.
The core steps above stay the same regardless of what you’re building, but where you look for evidence shifts depending on the project.
If your project spans more than one of these categories — a mobile app with an AI recommendation engine, say — ask for portfolio evidence covering each piece separately rather than accepting one all-purpose project as proof of everything. A developer who’s strong on mobile UI isn’t automatically strong on the machine-learning half, and a portfolio that blurs the two together makes it harder to know which skill you’re actually paying for.
Common Mistakes Non-Technical Founders Make When Vetting a Portfolio
Even careful founders tend to fall into the same handful of traps when they try to vet a developer’s portfolio under time pressure.

Vetting a developer’s portfolio without a technical background isn’t about learning to read code — it’s about refusing to accept a polished screenshot as proof of anything. Ask for live, working links. Check how recent the work actually is. Call the last three clients, not the hand-picked ones. Pay for a small trial task before signing anything larger. None of that requires an engineering degree, and together those four checks catch the overwhelming majority of expensive hiring mistakes before they happen.
TALK TO A VETTED TEAM DIRECTLY If you’d rather skip the vetting process altogether, GeeksSort’s portfolio, client list, and past project case studies are already public — you can review our shipped work and talk to past clients before you ever sign anything. Book a free discovery call and we’ll walk you through recent projects in plain English, no jargon required.📞 +880 1869-454674 🌐 geekssort.com
Focus on things you can judge without code: whether projects are live and usable (not just mockups), how recent the work is, and whether real clients will vouch for it on a reference call. A small paid trial task adds a fourth, very reliable signal.
A portfolio made entirely of design mockups or screenshots with no live, working link is the single biggest warning sign — it means you have no way to confirm the work actually functions.
Always ask for references, and specifically ask for the last three clients rather than hand-picked favorites. Broad questions like ‘were you happy with them’ rarely surface anything useful — ask about cost accuracy, communication under pressure, and whether they’d hire the developer again.
It’s one of the highest-value steps in the whole process. One to two weeks of paid, well-scoped work reveals how someone actually works — scoping, communication, and quality — in a way that no interview or portfolio review can replicate.
Toptal, Turing, and Arc.dev all pre-screen individual developers before they reach your shortlist, while Clutch and GoodFirms aggregate verified client reviews for agencies rather than freelancers.
No — a technical co-founder is one option, but a fractional CTO, a trusted engineer friend, or even a structured skills assessment like HackerRank can provide the technical judgment you need without giving up equity or waiting to find a co-founder.

Ebrahim KhanFounder & CEO