The Long Walk: What They Don't Tell You About Building Hardware in Germany

There's a moment every hardware founder knows. You're sitting across from an investor who just spent forty-five minutes nodding along to your pitch. You've shown them the prototype. The pilot contracts. The emails from fleet managers at rental car companies who are genuinely excited about what you're building. And then they lean back and say:

"This is really impressive. But have you considered a software-only approach?"

No. I haven't. Because the problem I'm solving exists in the physical world, and physical problems require physical solutions.

I spent two years building VoltVogel (autonomous robots for EV fleet charging). We had paying pilots with companies. Contracts waiting for the hardware. Fleet managers calling us asking when we could scale. The technology worked. The customers wanted it. And still, I watched the company struggle to raise because the batteries in our robots showed up on a balance sheet as depreciating assets, and that made investors nervous and the capital we would need to scale.

This is the story they don't put in the startup playbooks. Not the funding gap charts or the ecosystem comparisons. The human part. The part where you work eighty-hour weeks for months without a salary, prove your concept works, get customers to pay you actual money, and still can't get anyone to take the risk on you.

I'm writing this for the founders who are living it right now. And maybe for the investors who genuinely want to understand what it's like on our side of the table.

The Trust Deficit

Here's something that took me too long to understand: in the European hardware ecosystem, traction doesn't buy trust. It buys slightly longer meetings.

In a SaaS world, recurring revenue is proof. MRR goes up, investors get excited, checks get written. But in hardware, paid pilots get questioned. "Is this scalable?" "What's your unit economics at 10,000 units?" "How do you know they'll reorder?" Every proof point generates three new objections.

You learn to show up with answers. Detailed financial models. Manufacturing quotes from three suppliers. Regulatory timelines with buffer built in. And sometimes you do everything right, and the answer is still: "We love this, but hardware isn't our thesis."

I stopped counting rejections after fifty. Not because it stopped hurting—it never stops hurting—but because counting was making it harder to send the next email.

The thing nobody prepares you for is that rejection isn't the hard part. The hard part is the silence. The investors who say "let's talk next week" and then disappear. The warm intro that goes cold. The term sheet discussion that suddenly needs "more internal alignment." You're left checking your email at midnight, wondering if you said something wrong or if they just found a SaaS company with better margins.

The Grant Paradox

When private capital won't move, you turn to grants. In Germany, the grant infrastructure is genuinely good—EXIST, HTGF, various state programs. They gave VoltVogel a bit more time to build the prototype, to do the pilots and get the traction. (Our case was not a typical grant, as it was a hardtech accelerator program)

But here's what they don't tell you: grants come with their own gravity, and it can pull you off course.

Grant timelines run on government schedules, not startup schedules. You apply, you wait six months, you get approved, you wait three more months for disbursement. Meanwhile, your competitor is iterating weekly. The market is moving. And you're stuck because you budgeted around money that hasn't arrived yet.

Worse, grant objectives don't always align with what your customers need. A grant might fund R&D for a specific technical milestone—say, improving charging speed by 20%—while your pilots are telling you they actually need better scheduling software and faster deployment. You have to choose: chase the grant metrics or chase the customer need.

Some investors see grant funding as validation. Others see it as a warning sign. "Are they building a research project or a company?" I've been told by founders that question more times than I can remember. The honest answer is: we're building a company, we will take whatever resources we have at our disposal to make it succeed.

The cruelest part is watching the grant-funded R&D produce real breakthroughs that you can't capitalize on quickly enough because the reporting requirements and milestone structures have you moving at bureaucratic speed while the market moves at startup speed.

The Bureaucracy Tax

Speaking of bureaucracy: no one tells you how much of your week will disappear into paperwork.

There's the obvious stuff—company registration, tax filings, the Gewerbeanmeldung process that somehow requires you to physically appear at an office during working hours. But the invisible tax is worse. The compliance documentation that takes three days to prepare. The certification processes that require you to prove your robot won't harm anyone, which is reasonable, but the proving takes months and costs tens of thousands of euros. The grant reporting that demands you track every hour your team spent on each work package.

I remember a week where I spent more time on administrative tasks than on the actual product. That's not an exaggeration. Monday was investor prep. Tuesday was grant reporting. Wednesday was a tax and financial review. Thursday was a customer meeting that got rescheduled because I was still catching up on Wednesday's actual work. Friday was trying to remember what feature I had been working on before I was too busy with paperwork to check in.

Your competitors in the US aren't dealing with this. At least not at the same scale. And every hour you spend navigating bureaucracy is an hour you're not spending with customers or improving your product.

The People Who Work Against You

This is the part founders don't talk about publicly, because it sounds paranoid or bitter. But it's real, and pretending it isn't doesn't help anyone.

Not everyone wants you to succeed. Some people will actively work against you.

Sometimes it's a competitor who spreads doubt about your technology to potential customers. Sometimes it's an advisor who's playing both sides, feeding your strategy to someone else. Sometimes it's a team member who's already interviewing elsewhere and has mentally checked out. Sometimes it's an investor who passes on you and then warns others that your market is too small or your team is too inexperienced.

You can't let this make you paranoid. You also can't ignore it. The line between healthy skepticism and destructive distrust is razor-thin, and you'll walk it constantly.

I've had to work with people I didn't trust because they controlled access to something I needed—a customer relationship, a piece of infrastructure, a regulatory approval. You learn to compartmentalize. Share what you have to, protect what you can, and keep moving. But it takes a toll. Every time you have to smile through a meeting with someone you know is not on your side, a little piece of your idealism dies.

The startup mythology is all about the garage, the late nights, the brilliant insight that changes everything. Nobody talks about the politics. The power dynamics. The moments where you compromise something you care about because the alternative is watching your company die.

The Constant Defense

When you're fundraising, every conversation is a pitch. But even when you're not actively raising, you're still defending.

Defending your technical decisions to advisors who think they know better. Defending your timeline to customers who want it faster. Defending your strategy to team members who are nervous about runway. Defending your burn rate to existing investors who wish you'd grow slower. Defending your slow growth to potential investors who wish you'd move faster.

You become a professional explainer. Here's why we chose this architecture. Here's why we're targeting this market first. Here's why we haven't launched that feature yet. Here's why our roadmap looks like this.

The exhausting part isn't the explaining. It's that everyone has opinions, and almost no one has context. An advisor who spends two hours a month with you feels entitled to question decisions you've agonized over for weeks. An investor who hasn't talked to your customers tells you your market positioning is wrong. A friend who's never built a company suggests you "just need to focus more."

You learn to filter. But filtering takes energy, and energy is finite.

The Founder Question

The most important decision you'll make has nothing to do with technology or market or funding. It's who you build with.

Your co-founders will see you at your worst. They'll be there when the pilot falls through, when the investor ghosts you, when the engineer quits, when the prototype fails. They'll watch you doubt yourself. You'll watch them doubt themselves. And somehow, you have to keep showing up for each other.

The relationship has to be more than professional. I don't mean you have to be best friends—though that helps—but you have to genuinely care about each other as people. You have to be able to have the hard conversation at midnight after a terrible day. You have to trust that when they're struggling, they'll tell you, and when you're struggling, you can tell them.

I've seen co-founder relationships fall apart under pressure, and it's always the same pattern. Someone stops being honest. Small resentments accumulate. The hard conversations get avoided until they become impossible. And then one day, you're in a meeting realizing you don't trust the person sitting next to you anymore.

Check in with each other. Not just about work—about how you're actually doing. The company can survive a failed pilot. It probably can't survive founders who stop trusting each other.

Solving Real Pain

One of the few things that kept me grounded was a simple test: are we solving a real problem, or are we building a vitamin?

A vitamin is something that might help. A painkiller is something people desperately need. The distinction matters because when things get hard—and they will get hard—your customers' desperation is what keeps them engaged.

Fleet managers didn't want our robots because autonomous charging sounded cool. They wanted them because their staff was spending hours every day driving to charging stations, manually plugging in vehicles, their labor costs were rising, and their EV transition was stalling because the operational complexity was unsustainable. That's pain. Real, immediate, quantifiable pain.

The Mom Test—the book every founder should read—taught me how to distinguish genuine pain from polite interest. Stop asking people if they'd use your product. Ask them what they're currently doing about the problem. How much time and money are they spending? What have they already tried? If the answer is "nothing much," you don't have a painkiller—you have a vitamin.

Our best customer conversations weren't the ones where fleet managers said "that's interesting." They were the ones where they said "can you start next week?" That urgency is what you're looking for. It means you've found real pain.

The Iteration Trap

Here's the thing about hardware that makes it fundamentally different from software: iteration is slow and expensive.

When you're building software, you can ship a fix in hours. When you're building hardware, a design change means new molds, new certifications, new supply chain conversations. Weeks or months per cycle. And each cycle costs money.

So you have to be more careful. More deliberate. But the startup playbook says move fast and break things. These imperatives are in direct tension, and reconciling them is one of the hardest parts of hardware.

What I learned is that the iteration loop needs to happen at a different level. You can't iterate quickly on the physical product, but you can iterate quickly on customer conversations, on go-to-market strategy, on business model, on deployment process. The hypothesis-validate-iterate loop still applies—you just have to be smart about where you apply it.

Every week, we had new questions. Is our beachhead market right? Are we pricing correctly? Should we own the batteries or lease them? What's the real deployment timeline? You test hypotheses constantly, but you're testing them through conversations and small pilots rather than through rapid product changes.

The founders who struggle are the ones who build in isolation for eighteen months and then discover the market wanted something different. Talk to customers constantly. Let their feedback shape everything except the core technical insight—because if that's wrong, you should find out sooner rather than later.

The Story You Tell

In the early days, you have nothing but the story. No revenue, no product, maybe no prototype. Just two or three people and an idea.

The story is how you recruit your first engineer when you can't pay market salary. It's how you convince a customer to take a chance on an unproven product. It's how you get a meeting with an investor who doesn't usually take cold emails.

You have to learn to tell it well. Not in a manipulative way—people can smell bullshit—but in a way that communicates why this matters, why you're the right people, why now is the right time.

The story includes who you are. How you and your co-founder met. What experience you bring. Why this problem is personal for you. Investors at the early stage aren't really betting on your technology or your market—those are too uncertain to underwrite. They're betting on you. On your ability to figure it out, to persist, to adapt.

So the story of how you came together matters. The story of why you care matters. It's not manipulation. It's giving people a reason to believe.

The Resilience Question

I won't pretend I handled everything well. There were nights I couldn't sleep. Mornings I didn't want to get up. Weeks where the rejection felt personal in a way I couldn't shake.

Resilience isn't a personality trait you either have or don't. It's more like a muscle. You build it by using it, and sometimes by tearing it.

The things that helped: co-founders who knew when to push and when to support. A few advisors who'd been through it themselves and could normalize the struggle. Exercise, sleep, occasionally stepping away from the laptop. Small wins, celebrated genuinely—a customer call that went well, a technical milestone, an investor who said no but gave useful feedback.

The things that didn't help: pretending I was fine when I wasn't. Comparing myself to the highlight reels on LinkedIn. Thinking that if I just worked harder, everything would click.

Some days you question everything. That's normal. The question is whether you can get up the next morning and keep going anyway.

So Why Do It?

After everything I've described—the rejection, the bureaucracy, the politics, the self-doubt—why would anyone build hardware?

Because the problems are real and the need is urgent. Because change won't happen without people willing to bring about that change, and the climate won't fix itself without innovation and ingenuity. Because somebody has to build the physical things that make the future work, and it might as well be us.

And because there's something irreplaceable about watching a machine you designed do something that seemed impossible a few years ago.

The ecosystem is hard. The funding gap is real. The trust deficit exists. But so do the customers who need what you're building, and the engineers who want to work on problems that matter, and the small number of investors who actually understand hardware and are willing to take the risk.

I don't know if I'll build another hardware company. The honest answer is: it depends on the problem. If I find something important enough, something that can only be solved with atoms instead of bits, I probably will. Even knowing everything I know now.

Because the alternative—waiting for someone else to solve the hard problems—isn't really acceptable either.

If you're a hardware founder going through this right now, feel free to reach out. I can't promise I have answers, but I can promise I'll understand.