From Final Year Project to Startup
I spent part of today as a juror at Habib University’s Kaavish - final year project exhibition — walking out, I kept thinking about one thing.
How many of the projects I evaluated today are closer to a real business than their builders realise.
In a structural sense the foundations were solid. The problem domains were understood at a depth that only sustained engagement produces. The students had spent a year being accountable to real stakeholders — not a professor marking a rubric, but an organisation that actually cared whether the solution worked.
That kind of accountability is rare. It is also, not coincidentally, exactly what building a company feels like.
What follows is not an evaluation of what was built. It is an attempt to describe what the next step looks like — and why more students should be taking it.
What the Industry Already Knows
There is a reason companies invest in these programmes.
Industry partners who supervise final year projects are making a calculated observation: the students who spend a year solving a real problem, with real constraints, in a real organisational context, come out the other side with something that cannot be hired in through a job posting. They have domain depth. They have the scar tissue of a project that did not go exactly as planned. They have the experience of defending a position under pressure to people who are not obligated to be kind about it.
That is a foundation. The question that does not get asked enough — by the students themselves — is what to build on it.
The job market is one answer. It is not the only one. And for the students who spent a year genuinely caring about the problem they were solving, it may not even be the most interesting one.
Building your own thing is harder. It is also, if the problem is real and the understanding is deep enough, where the compounding begins. A job gives you a salary. A product built on genuine insight into a real problem gives you something that can outlast any single employer.
The Pattern Worth Noticing
The most consequential technology companies tend to start the same way — not with a unique idea, but with an unusually deep understanding of a specific problem, and the decision to take that understanding seriously.
Sualeh Asif grew up in Karachi and went on to MIT. While still a student there, he and three classmates built Cursor — an AI-powered coding environment — because they were frustrated with the tools developers already had. They made the problem personal before they made it a company. Cursor grew into one of the fastest-growing AI startups in recent memory, a valuation that places it among the most valuable developer tools companies in the world. Sualeh is 26.
Aaqib Gadit built Cloudways in Pakistan — a managed cloud hosting platform that made enterprise-grade infrastructure accessible to small businesses who could not afford the complexity that came with it. He focused on one problem, solved it with unusual care, and stayed close enough to his users to keep understanding what they actually needed. DigitalOcean eventually acquired Cloudways.
Neither of these started with an original idea. Both started with an unusually honest understanding of a specific problem — and the decision to stay with it long enough for that understanding to compound into something real.
That same starting point exists for many of the projects being built in universities right now.
The Space Is Never Empty. That Is Not the Problem.
Here is the assumption that trips up more early-stage projects than any technical challenge: that a good idea needs an empty space to exist in.
It does not. The space is never empty. Every problem worth solving already has someone working on it. The question is not whether competition exists. It is whether you understand your specific user well enough to find the detail that nobody else has handled yet.
Simon Sinek’s framing is useful here, though not in the way it usually gets applied. Start With Why is not about mission statements. It is about the prior question: why would a specific person choose your solution over what already exists? If you cannot answer that for one real person in one real situation, you do not yet have enough information to make good decisions about what to build.
Consider Bykea. It entered Pakistan’s ride-hailing market when Uber and Careem were already well established. Rather than competing on the same terms, it identified a specific user the existing platforms were not designed for — someone navigating dense urban traffic, needing an affordable short-distance ride, for whom a motorcycle was faster and cheaper than a car. That specificity was not a limitation. It was the entire strategy. Bykea did not try to serve everyone. It chose one user, understood that user’s actual day, and built around what that day required.
The Need Behind the Need
There is a further distinction worth making — between the problem a user will tell you they have and the problem that is actually costing them.
Users are good at describing symptoms. They are less reliable at diagnosing the underlying cause, because they have often adapted around it so completely that it no longer registers as a problem. It has become the way things are. The friction has been normalised. The workaround has become the workflow.
The most valuable products are rarely built on the problem users articulate. They are built on the problem that reveals itself only when someone pays close enough attention to how things actually work — not how they are supposed to work, not how the user describes them working, but what actually happens when a real person attempts to do a real thing in a real environment.
Careem did not discover that cash payments were necessary because someone asked for them. They discovered it because someone tried to pay with a card and could not. That moment — observed closely enough to be acted on — is where the insight came from. The same goes for building their own mapping system in a region where reliable street addresses did not consistently exist. Nobody filed a complaint about street addresses. The problem revealed itself only to someone paying close enough attention to how the experience actually worked. The need was always there. It took someone living close enough to it to see it.
This is what sustained engagement with a problem produces that no survey or user interview can replicate. The hidden need. The friction so embedded in the experience that the person experiencing it has stopped seeing it as friction. Finding that detail — and building something that addresses it — is where the most durable differentiation lives.
The students who spent a year embedded in a real domain, working alongside real organisations, have been closer to that kind of observation than most. The question is whether they were paying attention to it.
What a Company Cares About That a Demo Does Not Have To
A demo proves something can work. A company proves it keeps working — when the data looks different from what was expected, when users approach the problem from angles the design did not anticipate, when the conditions that felt stable turn out to be in motion.
The companies that endure are not the ones that predicted every change. They are the ones that built mechanisms to detect and respond to change as it happened. That distinction is structural. It is also designable — but only if it is thought about before the system is deployed, not after the first failure.
When inDrive entered Pakistan’s ride-hailing market, Uber and Careem were already established. Its core insight was not technical — it was structural. Instead of fixing prices algorithmically, inDrive let passengers and drivers negotiate directly.
That decision turned pricing into a feedback loop. Each ride became a data point — not captured after the fact, but embedded in the transaction itself. The market was not being predicted. It was being expressed.
That is why the model worked. It did not assume it knew the right answer. It created a mechanism for the right answer to emerge. Careem subsequently launched its own negotiation feature in direct response — the clearest possible signal that the late entrant had found something the market had been waiting for.
This is what a feedback loop means in a product context. Not ratings collected after the experience, but a system where real usage continuously shapes what happens next. The mechanism does not have to be complex. It has to be deliberate — designed in from the beginning, not added after the fact.
That deliberateness is what separates products that compound from products that stagnate. And it is as applicable to an AI pipeline as it is to a pricing model. Which is where the next section begins.
AI Is the Canvas. The Detail Is Still the Work.
Almost every project I evaluated today used AI in some form — LLMs, RAG pipelines, computer vision models, fine-tuned classifiers. And the starting point worth acknowledging is this: the barrier to building something real has never been lower. A working prototype that would have required a team of engineers and months of effort a decade ago can now be assembled in days. The cost of testing whether a problem is real, whether a solution resonates, whether the hidden need you identified actually exists, has collapsed. A student with a well-understood problem and access to current tools can put something in front of real users faster than most funded startups could five years ago. That changes the calculus of risk significantly — the excuse of not having enough resources to validate an idea is largely gone.
What impressed me was the fluency with which this generation of students has absorbed these tools. The ambition to apply them to genuinely hard problems — language preservation, accessibility, financial infrastructure, public health — was real and in several cases quite sophisticated.
The students who will build the most durable things are the ones who go one layer deeper: not just using the model, but understanding what it is actually doing well enough to know where it will hold and where it will not. A RAG pipeline that retrieves accurately from a curated corpus behaves differently on messy real-world data. An agent that navigates known scenarios encounters something different at the edges of its training distribution. The devil, as always, is in that detail — and the detail only reveals itself to someone who has thought carefully about the seams.
That deeper understanding is also what makes a feedback loop possible in an AI system — and a feedback loop is precisely what turns a capable pipeline into a differentiating product.
Just as inDrive embedded the market’s response into the transaction itself, an AI system can embed the user’s response into the pipeline — capturing when the output was useful, when it missed the mark, and how the context differed from what the model assumed.
In both cases, the system is not just producing an answer. It is learning from what actually happens when that answer meets the real world. In a market where the underlying models are increasingly commoditised, that mechanism is where the real differentiation lives.
What is equally underappreciated is that AI can teach about AI. The process of understanding which approach fits a given problem — whether a fine-tuned model serves better than a RAG pipeline, whether a classification algorithm is more appropriate than a generative one, whether the problem calls for computer vision or structured prediction — is itself a conversation that current tools can facilitate. The students who treat AI as a thinking partner in the design process, not just an implementation tool, will develop intuitions about these choices faster than any curriculum can deliver.
Building It Is Not the Same as Bringing It to the World
There is a generation of engineers ahead of you who built genuinely useful things that nobody ever found. Not because the product was weak. Because the path from a working product to a user who knows about it, chooses it, pays for it, and stays with it — is its own discipline, as demanding as the engineering itself.
The technical problem and the commercial problem are different problems. Solving one does not solve the other. And the commercial problem — how does this reach the people who need it, at a price that sustains the work, through a channel they actually use — is one that engineering training rarely addresses directly.
Previous generations of engineers largely had to discover this on their own. That gap in awareness was the norm. It is less excusable now, not because the challenge is smaller but because the knowledge is more accessible. There are more examples, more frameworks, more founders who have documented what they learned. The raw material for understanding commercialisation is available in a way it has never been before.
What that understanding actually requires, in practice, is thinking through a few questions that the product alone cannot answer.
Who pays for this — and is that the same person who uses it? In many of the projects built this year, the user and the economic buyer are different. A platform built for students may be paid for by an institution. A tool built for farmers may be funded by an agricultural development programme. Understanding that distinction changes how you price, how you sell, and what features matter most to whom.
How does someone discover this exists? A product that solves a real problem is still invisible until it reaches the person who needs it. The channel through which a potential user encounters and evaluates your solution is as much a design decision as the interface itself. Cloudways grew largely through word of mouth within communities of developers and small business operators — because the product was good enough that the people using it told others. That was not accidental. It was the result of understanding who the early user was well enough to build something they would naturally recommend.
What does it cost to serve one user, and does the price reflect that? The projects built this year were almost universally free at the point of use. That is appropriate for a capstone. It is not a sustainable default for a product. Understanding the economics of delivering value — what it costs, what a user would pay, where the margin lives — is the layer of thinking that turns a technically sound product into something that can sustain itself and the people building it. Sometimes the pricing model itself is the insight. inDrive did not just build a negotiation feature — it recognised that in a price-sensitive market, letting users and drivers agree on a fare directly was more trusted than any algorithm. The price became the product’s clearest signal of respect for its users.
None of this requires a business degree. It requires the same disposition that produced the product in the first place: curiosity about how things actually work, willingness to sit with the uncomfortable questions, and enough respect for the user to understand not just what they need but what they will actually do.
The Thing That Does Not Show Up in the Demo
The projects that stayed with me after today were not always the most technically sophisticated. They were the ones where the student had made the problem genuinely their own.
That is harder to describe than it is to recognise. It shows in how questions are answered — not whether they are answered, but whether the student reaches for their own understanding or for a prepared response. It shows in the honesty with which limitations are acknowledged. It shows in the specificity of what they would build next, and why.
That kind of ownership does not come from the project structure. It comes from caring about the problem independently of the deadline — thinking about it outside supervised hours, noticing its dimensions in daily life, having views about what the second version should look like before the first one is finished.
It is also the quality that matters most when the academic structure falls away and the only reason to keep going is that you believe the problem is worth solving.
Cursor was built by students who were genuinely frustrated with their own tools. Cloudways was built by someone who believed small businesses deserved infrastructure they could actually use. Careem was built by someone who grew up in Karachi and understood urban mobility in this part of the world at a level that no amount of research could replicate.
In each case, the problem was personal before it was a company. The passion came first. Acting on it came from trusting that the understanding was real.
What the Next Step Actually Requires
A project answers one question: can this be built? A product answers a harder one: will someone use this repeatedly, when nobody is asking them to? A company answers the hardest one: can this survive in the real world, when the conditions change and the original assumptions no longer hold?
Projects prove you can build. Products prove someone cares. Companies prove it survives.
For anyone who built a final year project this year — at any institution, on any problem — the questions worth sitting with are simpler than they might appear.
Do you know the specific person your solution is most useful for — precisely enough to describe a day in their life? Do you know what already exists for them, and exactly where it falls short? Do you have a mechanism by which your system will learn from what actually happens when real people use it? And do you understand what it costs to serve one user, who pays for it, and how they will find out it exists?
These are not business questions layered on top of engineering. They are the next layer of the same problem you have already been working on. The domain knowledge is already there. The year of engagement already happened. The foundation is already built.
The advantage you have right now is not just insight. It is time — the freedom to explore a problem before the world forces you to move on. That window is real, and it is finite.
What happens with it next is yours to decide. And that decision is where most projects either end — or begin.
TECTONICS is a series about how technology organisations actually move — the systems, culture, and scale decisions that determine whether they compound or collapse.