Software pilots for your next big thing.
Hi. I'm Daniel, a software engineer.
I make episode 1 of your idea before you commit to the season:
Production-ready pilots in 8 weeks, at a fixed price.
Innovation starts with a bet.
To stay competitive, you have to explore new technology. Integrating AI, modernizing your stack, adopting new platforms: These are the bets that create competitive edge.
But you can't know if they'll work until you try them.
So what do you base the decision on? A sales pitch, a controlled demo, and what, vibes? Will it work in your context? With your data? At your scale?
You're flying blind. And that's when expensive mistakes happen.
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■ ■■■■■■■■■
■■■■■■■■■ ■■■■■■■■■
■■■■■■■■■ ■■■■■■■■■ ■■■■■■■■■
■■■■■■■■■ ■■■■■■■■■ ■■■■■■■■■ ■■■■■■■■■
───────────────────────────────────────────────────────►
Discovery Validation Implementation Release
If it fails, you own it.
The vendor moves on. Your team unwinds the mess. The budget is gone, your credibility is damaged, and you're behind on features that actually make money.
You've probably seen it before. The data project that failed in production. The rewrite that turned into 18 months of toil. The early platform decision that you're still paying for.
The cost of mistakes compounds over time. Every day on the wrong path is a day not exploring better options.
──┐ ──●─────x ──────────┐ ──────────●──┐ ─────────────●───x ────────────────────┐ ────────────────────●──────────►
Make episode 1 first.
Don't analyze it to death. Don't plan the whole thing.
Build the essentials: the parts that prove if it actually works.
The television industry has got this figured out. You don't film a throwaway. You film the first episode. When the studio buys the season, the pilot is the first thing they air.
Software pilots should be the same. Real, solid, and ready to go live.
If it works, you've got your production foundation.
If it doesn't, you save yourself a fortune.
Tech demos in controlled environments
Targeted prototypes tested in your business context.
PowerPoint recommendations
Production-ready code with documentation and tests.
Endless debates about what to do
Evidence-based go/no-go decisions from experiments.
Big commitments, up front
Short engagements with natural stopping points.
Past work: Testing a new hardware frontier.
When Apple announced the Vision Pro, a big question surfaced: could this be the company's next hardware platform? I built a native proof-of-concept in a month and stress-tested the development pipeline, uncovering critical tooling limitations.
Outcome: Avoided a costly mistake with clear evidence for a "no-go" decision. The prototype became a valuable marketing asset.
The 8-week pilot.
Pilots optimise for learning, not predetermined outcomes.
I fix the risk: time, cost, quality.
You stay open to: what we discover shapes what we build.
The work involves the following core activities. The specific mix, order, and priority depends on what you're trying to prove.
Pilot activites:
Map the landscape
Understand your context, constraints, and objectives. Find viable approaches and analyze trade-offs. Establish clear decision criteria.
Test assumptions
Build targeted prototypes to validate the risky parts. Does it perform? Will it integrate? Do vendor claims hold up?
Build the essentials
Create the core product: episode 1 of your technical idea. Production-grade. Documented, tested, ready to extend.
Gather evidence
Measure what matters. Performance data, integration tests, cost projections. Real data that informs your decision.
Recommend next steps
Synthesize what we learned. Should you continue? Pivot? Stop? I give honest, evidence-based recommendations.
What you get.
By the end of 8 weeks, you have:
- Working software that proves (or disproves) your concept
- Clear documentation of what works, what doesn't, and why
- Production-ready code your team can build on if you continue
- Honest assessment of whether to proceed, pivot, or stop
Sometimes we discover the concept works brilliantly. Sometimes it needs a different approach. Sometimes it's too big to pilot and needs a long-term R&D team.
All of those are valuable outcomes.
Past work: Escaping vendor lock-in.
When a critical vendor skyrocketed their price, a technology company faced existential risk. I mapped five open-source options, prototyped the top two, and validated the winner through a customer-facing pilot.
Outcome: Proprietary dependency eliminated, massive licensing increases avoided, and production-ready architecture delivered in months. The first client project on the new platform went live shortly after.
About me.
For a decade, I've delivered solutions at the edge of what's possible: from deep learning before ChatGPT to extended reality before the Metaverse. I've worked with companies like LEGO, Salling Group, and Siemens Gamesa.
Now I help technology leaders prove out ideas before they bet big.
"I highly recommend bringing Daniel in to help solve wicked, convoluted development problems. Especially when there is no easy solution and it requires input from several different domains."
> Kristian Too Andreasen, CEO at Kanda
Some background:
- Former CTO at Kanda, leading tech strategy and product development.
- Former ML engineer at LEGO, building intelligent moderation systems.
- Built SynthVR, a commercial VR product, from concept to profitable release.
- Open source contributor and technical writer.
Here's what I learned: You can't de-risk complex technical work through analysis only. You de-risk by building something real. By proving it works before betting big.
That's why I build software pilots.
Why 42?
Those who know "The Hitchhiker's Guide to the Galaxy" recognize 42 as the answer to the "Ultimate Question of Life, the Universe, and Everything."
The right answer is meaningless without the right question. Many projects fail by solving the wrong problem well. My pilots begin with getting the question right.
// // /////
// // // //
//////// //
// // /
// //////// Past work: Hiring at scale.
A major retailer needed a way to screen thousands of job applicantions efficiently. I ran experiments comparing multiple approaches. Evidence showed a simple model outperformed more sophisticated alternatives.
Outcome: Delivered a practical solution from hypothesis to production API, with guidance on managing algorithmic bias at scale.
Transparent pricing.
8 weeks. €30,000. Fixed price.
I make episode 1 of your idea: production-ready software that proves if the concept works.
Early exit available: If we discover early that the concept isn't viable or the scope is too big, you can stop. I'll refund 50% of the remaining work.
Sometimes the pilot reveals you should continue. Sometimes it reveals you should stop. Both outcomes save you from expensive mistakes.
Need something different? Let's talk. The goal is to get you the clarity you need.
Ready to go?
Book a call to discuss your technical challenge. We'll explore how a structured software pilot could support your next big thing.
* .--.
/ / `
+ | |
' \ \__,
* + '--' *
+ /\
+ .' '. *
* /======\ +
;:. _ ;
|:. (_) |
|:. _ |
+ |:. (_) | *
;:. ;
.' \:. / `.
/ .-'':._.'`-. \
|/ /||\ \|
_..--"""````"""--.._
_.-'`` ``'-._
------' '-------Or maybe you prefer to DIY?
No problem. If you want to run your own pilot, I'll share my approach. The Software Pilot Manual walks through structured validation: gathering the data, designing experiments and doing production-ready prototyping.
Email me, and I'll send it to you.
I also write about technical decision-making, software design and emerging technology:
Frequently asked questions.
Why 8 weeks specifically?
Eight weeks is long enough to build production-ready software that proves your concept, but short enough to maintain focus and momentum.
Less than 8 weeks, you end up with throwaway prototypes that don't tell you if it works for real. More than 8 weeks, you're not piloting anymore: you're building a full product without knowing if the essentials are solid.
Some projects need 6 weeks. Some need 10. But I've found that 8 is a sensible default that works for most software pilots. If your needs are different, we can adjust.
Can't I just assign this to my own team?
You absolutely can. If you do, email me and I'll share my Software Pilot Manual.
But if your engineering team is busy shipping and you want an unbiased perspective from seasoned engineer, I can help.
What if the pilot fails?
A pilot that reveals "don't do this" is a success, not a failure.
Consider the alternative: assign 3 engineers for 6 months and then discover it doesn't work. That costs 10x more and blocks you from pursuing better opportunities.
Whether the pilot reveals you should continue or stop, you get clear evidence for your next move. Both outcomes save you from expensive mistakes.
How much of my team's time will this consume?
Minimal. The engagement is designed for high autonomy and low overhead.
Your team's involvement typically happens at three points:
- Kickoff: One workshop to align on the problem, success criteria, and technical context.
- Check-ins: I provide async updates. Your team only joins if specific questions arise.
- Handoff: Final session to walk through deliverables, documentation, and next steps.
Most weeks, your team focuses on shipping while I focus on the pilot.
Have you worked with our specific stack / domain / industry before?
My experience spans cloud infrastructure, machine learning, and application development across energy, manufacturing, and retail.
But my core value isn't knowledge of a specific stack: it's expertise in the process of technical validation itself.
I'm a hands-on engineer who can learn your context quickly. For deep niche challenges, I work with a network of senior specialists to maintain momentum.
What exactly does "production-ready" mean?
It means we build episode 1 properly, not as a throwaway prototype.
The goal isn't a full product in 8 weeks. It's the essential core built to production standards: because that's how you prove it actually works.
Every pilot includes:
- Working software with a sensible test suite
- Clear documentation of code and architecture
- Observability hooks for logging and monitoring
- Handoff instructions for your team to extend it
What's essential varies by project. The quality standard doesn't.
Can we stop early if things aren't working out?
Yes. If we discover early that the concept isn't viable or the scope is too big, you can stop. I'll refund 50% of the remaining work.
My goal is to eliminate risk, and that includes the engagement model itself.
You always have a way out.
Stay updated.
I regularly publish technical analysis on on my blog. Subscribe to get new posts: