Manufacturo, The Creation Story

The “We Need to Build Our Fifth Sun” Moment

The Manufacturo Creation Story begins with an honest admission: we did not set out to build a manufacturing management platform.

In 2014, Łukasz Gorka, Paweł Mierzwa, Grzegorz Fura, and I founded another company, Andea, which still operates globally today. Our focus was implementing existing manufacturing execution systems (MES).

Across hundreds of MES implementations, we consistently saw the same patterns. The repetition revealed that the industry was weighed down by inefficiencies.

Many customers needed comparable capabilities — work orders, inventory, traceability, labor management — yet each engagement required teams to script these functions from scratch. Projects stretched for months and often cost millions. So we asked ourselves: why not build a model once, instead of recreating the metaphorical wheel every time?

For years, the idea lived in our heads and in scattered custom code. Then, in a conversation among the Andea founders, we finally articulated the real questions:

We realized the answer was not another project, but a product. One we would need to build ourselves — our own Fifth Sun.

Belief, Grief, and Renewal

Our vision started to take shape in late 2018. We sketched a platform built around modular apps that shared a common data backbone but had distinct purposes and independent release cycles. I imagined something like a smartphone - straightforward to configure, user friendly, and with an app store for whatever was needed.

We believed we could have a minimum viable product within a year and hit the market with one strong app release after another. It was wildly optimistic and naive. But the strength of our beliefs pushed us forward.

But some people stayed on.

Maybe against their better judgement or out of pure stubbornness, a few dedicated teammates refused to throw in the towel. We banded together and fought through. We learned from our many mistakes and kept our eyes on improving methods and tools. Gradually, the situation stabilized. (I will be forever grateful for those dedicated, creative core builders.)

Finally, after many brutal months, we reached the turning point; our technical validation was complete. The architecture worked in practice. The product was mature enough to support real customers.

It was the time to level up and build apps for the platform.

But another level up… and more roadblocks.

Our first instincts proved to be too safe. We weren’t reaching far enough. We were merely extending legacy apps and structuring around them.

It should come as little surprise that this approach did not attract new customers. It pulled us deeper into technical debt, costing us months as we debated our product focus.

Over a year into the process with the core architecture constructed, and after many failures and triumphs, and we had no real identify. Our central questions transitioned from the technical to the existential.

Who are we and who do we help?

Go broad or go deep?

Remain industry agnostic?

Or chase a sector that would truly test the system?

We already had several on-prem apps in production, so we used them as proof points for the new platform. We migrated the existing tools to the platform, creating a flexible model to host custom apps. Around the same time, we persuaded some customers to move from on-prem to our cloud solution.

Then the problems came.

Our legacy applications were not designed for the new tech stack, nor did they integrate cleanly with the platform. Going live with SaaS meant shifting from pure development to operations, and we had not substantially assembled a team or process to support it. We forced a few organizational errors too, including in how we tested and released software, how we deployed to production, and how we monitored, diagnosed, and troubleshot issues.

We made mistakes, I made mistakes.

Resignation letters came in from key players. We were stuck in the proverbial dark tunnel with no end in sight. It was painful. I had moments of serious doubt:

What was I thinking starting all of this? Is there a way to make it work? 

A New Sun for New Space

A couple of key players helped us answer those who are we questions.

Manuel Julien, who had worked at SpaceX before starting Andea’s U.S. operations, was proving that  the SpaceX culture of rapid iteration and true ownership could thrive outside the company’s Hawthorne headquarters. That mindset deepened when he brought in James Montgomery to run our services business.

When James joined the product discussion, he offered a bold, prescient proposal: focus on the New Space industry.

In hindsight, the timing couldn’t have been better. Private investment in New Space was reaching record levels. Relativity Space, for instance, had just raised 650 million dollars.

The public was pumped about new space advancements. SpaceX launches were widely watched, with laypeople talking up their emerging technologies - the reusable Falcon 9 cores and Starship payloads - at bars and around office water coolers. Industry metrics told the story in numbers as well: commercial space was projected to grow 11 percent annually.

But just as significantly, the industry was shaped by people who thought like us. Many were SpaceX alumni, like several of our team members. They were throwing out old playbooks, rewriting the rules of space manufacturing and exploration.

No longer moving at a 20th Century pace, the new space leaders believed in iterating quickly - and they expected their systems to keep up.

So we made the call: create a manufacturing management system for the most demanding sector on planet Earth.

With this lofty but attainable vision, we brought other great minds for system innovations on board. Kenzo Takai joined, bringing more than 20 years of MES experience from Apriso, SpaceX, and iBASEt. Soon after Zane Shewalter was added to the team, leveraging his deep experience at SpaceX, Blue Origin, and Opentrons.

This was the true turning point.

No longer were we consultants configuring other platforms, or conceptualizing our own product. We were builders driven by a clear mission to fashion something better for an industry taking off in every sense of the phrase.

A Tech Rebels Collaborative

At heart, our motivation was simple. We were colleagues with a shared passion for tech innovation and close customer collaboration. Our driving force then, and now, was improving real-world outcomes for our customers. Their successes were our successes.

But we were also, in our own quiet, not-so-obvious way, rebels. Not James Dean types with cigarettes dangling from our mouths wearing pained, bored expressions suggesting existential angst. Nope.

We were tech rebels.

Data at our fingertips, continual improvements on our minds, wearing expressions of hope for the future - and okay, sometimes a furrowed, skeptical brow.  

And this is what we, a band of tech rebels, were up against: legacy players who dominated the market for decades.

They delivered rigid solutions and slow implementations to customers struggling under the weight of these behemoth systems. Projects dragged on. Changes were expensive. Users had to adapt to the software.

As tech rebels, we thought, shouldn’t it be the other way around?! Shouldn’t the system adapt to the user?

Our rebellious focus was singular - build software that solves problems adroitly. Quickly, smoothly. Allow New Space and akin industry innovators to innovate. Make them successful.

This approach resonated with our first customers in 2021, who were startups and market challengers like us. Like begets like.

Our company and our customers were disrupting industries. They needed software that could keep up with their pace of change. We needed future-focused customers willing to build the novel together.

Quality at the Core

In addition to legacy systems being as agile as a stone pillar, their architecture was too prone to quality escapes. Their quality was bolted on, rather than embedded into and guiding the system.

A famous and expensive failure paints the picture…

It was 1990. It was the era of hair bands and landlines. The Cold War had just ended and malls were all the rage. People listened to music on tapes and watched movies on VHS. A major scientific event  was the launch of the Hubble Space Telescope.

It was a $1.5 billion dollar investment that proved to have a major defect: blurry vision. Yes, a 1.5 billion dollar telescope that couldn’t focus.

The root cause was astonishingly small. A spacing washer in the mirror grinding equipment was off by 1.3 millimeters. This tiny error created a 2,200 nanometer aberration.

The NASA investigation bluntly concluded, "This was a failure of management and quality assurance."

World-class opticians, engineers, and technicians assembled this ambitious technology but all the talent in the world couldn’t overcome the core issue, that the process around them was wrong.

Quality checks happened after manufacturing steps, rather than synchronistically. Quality was the afterthought, not the system. By the time anyone identified the Hubble’s small but massive problem, the defect was intractable.

And we see the same issue decades later.

MES platforms haven’t learned this quality-should-be-first lesson.

Too many systems attach quality as a checkbox. They allow work orders to close with gaps or manual notes to be kept on the side. They separate compliance from execution.

These systems open the flood gates for defect escapes.

Build It In, Don’t Bolt It On

Embedding quality into Manufacturo's DNA from day one, and making it a core differentiator, was of the highest importance in creating our product. Zane, being the quality guru that he is, has been instrumental in leading the way on our quality-by-design, quality-at-every-step model.

Combined with our change control capabilities, this quality-first approach allows manufacturers to introduce frequent design modifications methodically. This is absolutely essential for high-tech emerging companies that iterate rapidly.

Here’s a real-life example…

In early 2024, Hermeus, an aerospace and defense technology company, came to us with a process problem. They were building hypersonic aircraft at a Mach 5 pace and their operational system couldn't keep up.

We heard their concerns loud and clear: "We are relying on tribal knowledge... It’s hard to keep track of so many moving parts... If something went wrong, it was very hard to identify the root cause."

Less than a year after switching to Manufacturo, Hermeus released Quarterhorse Mk 1 - designed, built, and flown in just 18 months. Their approach was simple: build Mk 0, learn. Build Mk 1, learn faster.

Iterate and learn fast.  Improve on each iteration. Tackle harder problems.

That rock-n-roll, new space rhythm hinges on software supporting change and keeping traceability fully intact and visible from end to end.

That is exactly what Manufacturo is designed to do.

Beyond the Origin Story

Manufacturo was born from iterating on years of deployments, refining patterns, discarding what did not work, and expanding what did. The same discipline that took us from project work to a product platform governs how we continue to evolve.

We built Manufacturo for companies that think the same way. Their approach is not static, never an unalterable blueprint.

They move quickly in every way. They change designs, routes, and processes. All while maintaining firm control over quality or traceability.

Our job is to turn that cycle of build-learn-improve into repeatable iterations that is safe to scale.

The innovators we work with are continuously rewriting what is possible in aerospace, defense, advanced energy, and beyond. Their stories do not stop at an origin moment, and neither does ours.

Our role in this creation story is clear - provide the platform that lets cutting-edge manufacturers iterate with confidence as they engineer the breakthroughs that shape our world.