← Back to all posts

What to Do After You Build Something That Works

He shared his screen. On the left, a simulation of a robotic arm tracing a toolpath. On the right, the same arm doing it for real, shaping a sheet of metal into a precise geometric form, accurate to within seven percent of the design. Three years of work, reduced to two windows on a laptop.

I asked him what he planned to do with it.

“Right now,” he said, “everything is either in my PC or in my mind.”

I have had a version of this conversation more times than I can count. Someone finishes the part of the work that is genuinely difficult: years of expertise compressed into a system that did not exist before, now sitting in front of them and working. And then they stall, completely, on the part that comes right after. Not because they lack the answer. Because nobody ever told them this part of the job existed.

A recent conversation with a former student, now deep into a robotics and metal-forming project in Germany, brought the pattern into sharp focus. He had built something real. He had no idea what to do with it. The advice that cleared his path is the same advice I find myself repeating, in different fields and different countries, to people who are every bit as capable as he is.

The Part of the Job Nobody Trains You For

Most technical training prepares you for one thing: solving the problem directly in front of you. Build the model. Run the simulation. Get the system to do what you designed it to do. Years of coursework, supervision, and feedback all point toward a single outcome — a working result.

Almost none of it prepares you for the moment after the result arrives.

That moment looks different in every field, but its shape is always the same. You have produced something that did not exist before: a method, a dataset, a prototype, a working system. And now you are standing in front of it, facing a question your training never addressed. What is this actually worth, and to whom?

That is not a technical question. It is a positioning question. For someone who has spent years becoming excellent at the technical question, it can feel like the ground shifting under their feet — not because they are unprepared in general, but because this specific kind of question was never on the syllabus.

What a 93-Percent-Accurate Robot Arm Actually Proves

Let me describe what he had actually built, because from the inside it is easy to underestimate the size of it.

He had taken an industrial robotic arm designed for an entirely different job and reprogrammed it, from the ground up, to perform incremental sheet forming — shaping thin metal sheets gradually with a single moving tool tip, instead of stamping them in one motion with an expensive custom die. He wrote his own inverse-kinematics solver so the system would adapt to different robots rather than being locked to one. He built force thresholds so a lighter, collaborative robot would not damage itself or the material. He built a digital twin that mirrored the physical robot's motion in real time, side by side, on the same screen. Then he scanned the finished parts and checked them against the design: geometrically sound, with the formed shape landing at ninety-three percent accuracy against the simulation.

He listed all of this in a flat, matter-of-fact tone, the way you describe something you have lived inside for so long that you can no longer see it from the outside. I told him plainly: this is not a small thing. Building a working demonstrator, one piece of hardware and software that proves an idea functions in the real world, is often the single hardest step between an idea and an industry. Most projects never get this far. He had.

He had not registered any of it as an asset. To him, it was simply the assignment: the thing he had been asked to do, now mostly finished. The idea that it might be worth patenting, publishing, or building the next decade of his career around had not yet entered the frame.

Stop Waiting for Someone to Hand You the Next Step

Here is where the conversation took its sharpest turn.

He had a plan forming, vaguely. Tell his supervisor. See what the team wanted to do with it. Wait for direction.

I told him to reverse the order.

Before you announce anything, find out what they are already planning. What is their timeline? Do they want to keep this private, patent it, publish it, or build a larger project on top of it? Once you know their direction, you will know exactly where you stand inside it, and whether staying inside it gets you where you actually want to go.

But do not confuse finding out their plan with waiting for their plan. The moment you know where things stand, the lead is yours to take. Decide what you want this work to be known for, and say so clearly, and first. The alternative is spending years building something remarkable inside someone else's narrative, then discovering, much later, that the narrative was never going to put your name where you expected it.

This is rarely about conflict with a supervisor or a team. Most of the time, nobody has thought this far ahead, and a clear voice in the room is welcome. But somebody has to be the one who says: here is what we have, here is what it could become, and here is the plan to get there. If you are the one who built it, that person should be you. If the bigger question underneath this one is whether to stay in academia at all, this look at the academia-versus-industry decision in engineering goes deeper into that specific fork.

Patent It, Publish It, or Lose It

Once you decide to own this, two moves matter, and they are not in competition with each other.

Build a public, peer-reviewed record. A publication. A patent. Ideally both, in the right order: generally, secure the patent before a publication makes the idea public, since a patent filed after disclosure can be far harder to defend. A peer-reviewed record does something a private demonstrator cannot. It puts your name, permanently and verifiably, on the thing you built. It stops being a claim. It becomes a record that someone else has checked and confirmed.

Treat the work as part of your identity, not a deliverable you hand over and walk away from. This is the part most early-career researchers miss completely. A finished project is not the end of your relationship with the work. It is the beginning of a different one. Wherever you go next, a new role, a new country, a new field, the work travels with you if you decide to carry it. Put it on a public repository. Record the demonstrations. Write the case study. The version of you applying for the next position, the next grant, or the next investor is not starting from zero. They are starting from: here is something I built that works, and here is the proof.

Skip both of these and the demonstrator stays exactly where it started: on a laptop, known to a handful of people, worth nothing to anyone who was not in the room when it was built.

The Ownership Test

Before deciding what to do next with anything you have built, a model, a tool, a process, a working system, run it through three questions.

Is there a public, peer-reviewed record with your name on it? If the answer is no, that is where you start. Not with more technical work. With making what already exists impossible to overlook or quietly reassign.

Could you explain, in one sentence, what makes this yours? Something nobody else on the team could have produced in quite the same way. If you cannot answer cleanly, you do not yet have a unique selling point. You have a contribution to someone else's project. Those are not the same thing, and only one of them builds a career.

If you left tomorrow, a new job, a new country, a new field, would this travel with you, or stay behind? If the honest answer is “stay behind,” that is the clearest signal of all. The asset currently belongs more to the place than to the person who built it. That is fixable. But only if you notice it before you are already gone.

If you answer no, or you are not sure, to any of these, you are not behind. You are standing at the exact point where most capable people stall: the point where the technical work is finished, and the ownership work has not yet started.

Going Public Is a Beginning, Not a Finish Line

A patent or a publication feels like an ending. You spend years building toward it, and then it exists: permanent, verifiable, attached to your name. It is tempting to treat that moment as the finish line.

It is closer to a starting gun.

The distance between “I have a working demonstrator” and “this is now a fundable, scalable, commercial technology” is not measured in months. In most fields, it runs five to six years. That gap does not close on its own, and it does not close through more lab time either. It closes through visibility — the right collaborators, funders, and industry partners actually seeing what you built and understanding what it could become next.

Once your work is public, your role changes. You stop being only the person who built the thing. You become the person who explains it: what has been proven, what is still open, and what it would take to close the rest of the distance. That is not self-promotion in the uncomfortable sense of the word. It is telling the truth about your own work, clearly and on purpose, to people who are positioned to help finish it.

The pitch, when you are ready to make it, does not need to be complicated. We have built and proven a working demonstrator. Four or five specific things remain before this becomes an industrial process. Here is what each of them will cost, in time and in funding. Here are the collaborators who are already on board. That is a fundable proposition. A demonstrator sitting quietly on a laptop is not.

Two Ways to Build the Next Five Years

Once you know you intend to keep building on this, there are two broad ways to do it. Neither is automatically the right one. The choice depends on your infrastructure, your patience, and who you already know.

The first path is to grow it one piece at a time. Take on smaller, funded projects, one domain at a time: the materials side, then the data-driven modeling side, then the mechanical performance and testing side. Each project deepens your record and your reputation in that specific corner of the field. This path rewards patience, and it produces a researcher who is recognised, narrowly and deeply, as the person who owns this problem.

The second path is to make one larger, coordinated bet. Assemble three to five collaborator groups, each owning a different domain — mechanical development, data-driven modeling, application and performance testing — and apply for funding that runs all of it in parallel. Done well, this compresses years of incremental progress into a single funded cycle, often three to four years, and ends close to a commercially viable process.

If you have strong infrastructure, a patient timeline, and not yet many collaborators: start with the first path, and let it build the relationships the second path will eventually require. If you already have visibility, momentum, and people in adjacent domains who would say yes to working with you: the second path gets you there faster, with more of the credit landing on your name.

Name where this leads, because both paths arrive at the same place eventually. From there, one of two things happens. An established company folds the technology into its existing operations as a new capability it now owns. Or a new investor backs a dedicated operation built around it — usually a high-mix, low-volume manufacturing setup, the kind that proves a new process on real parts before anyone commits to scale.

If you do not drive toward one of those two outcomes, the opportunity does not wait quietly for you to come back to it. It moves. If you do not invest the next phase of effort into this, an investor eventually will, on their own terms. If no investor steps in, an existing industry player will adopt the idea and fold it into a branch of its own operation. Either way, the work you have already done becomes someone else's head start, not yours.

Final Thought

By the end of the conversation, something in his posture had changed. Not because I had told him anything about robots, or forming, or force thresholds. He knew far more about all of that than I ever will. What shifted was simpler. He realised that the part he believed was still ahead of him, the hard part, was substantially behind him already.

What remained was not more building. It was claiming what he had already built: writing it down, making it public, putting his name on it somewhere permanent, and carrying it forward as something that belonged to him, not only to the project that funded it. If the feeling of having finally built enough to calculate exactly what is at stake sounds familiar, this piece on mid-career paralysis looks at the same pattern from a later vantage point, and the one question that cuts through it.

That is the part nobody trains you for. And more than any technical skill, it is the part that decides whether years of excellent work become a career, or quietly become someone else's case study.

Built Something. Not Sure What It's Worth?

Book a 15-minute call. We will look at what you have actually built, name your unique selling point in plain language, and map the difference between the work that is done and the ownership work that is not. If you do not need help with this, I will tell you that too.

Book a 15-Minute Call Send a Message

If You Are at a Similar Crossroads

Building something that works is rarely the end of the decision. It is often the moment a much larger one quietly opens up.