You have an idea. No tech team. No path forward.

It happens to almost every founder I meet. There's an idea — sometimes a long-considered one, sometimes a sudden one — that won't let go. You see the shape of the product. You can almost feel how customers would use it. But the path between idea and a running thing on the internet is foggy: do you start with a designer, an agency, a freelancer, an AI tool? Quotes come in at €80–120k for what you suspect should cost a fraction of that. People nod, take a brief, disappear for two months, come back with something that's almost it but not quite. The idea quietly stays an idea. Ideas don't get stuck because they're bad ideas. They get stuck because nobody is sitting in the seat where concept, code, server and growth all live in the same head — willing to think the whole thing through before committing money to building the wrong thing.

Most engineers love writing code. I love that too — but the part I genuinely get my energy from is the moment a vague idea becomes a concrete plan. Sketching the functionality on a whiteboard, finding the angle the competition has missed, spotting the early tripwires, deciding which 20% of features actually matter for v1 and which 80% are tempting but should wait. Fifteen years of doing this means I've also seen which ideas didn't work and why. The ones that died because the founder fell in love with a feature nobody wanted. The ones that died because the technical choice in week one made every later choice impossibly slow. The ones that died from over-scoping. I've taken multiple concepts from zero — including one I built, ran and scaled to roughly €60k/month in revenue — and the pattern recognition behind that is what you actually buy when you bring me a concept.

Before we touch a code editor we do the work most builders skip. Concept design: what is this thing actually, in two paragraphs, for whom, against what existing options, with what unique angle. Competitive research: who's already in this space, what they're charging, where they're weak, where the gap is real and where the gap is just bad marketing. Feasibility: is the technical part of this realistic given the budget and timeline, or is one of those numbers wrong by a factor of three. Functionality scoping: which features ship in v1, which in v2, which never (and why). The deliverable from this phase is a written concept document — your idea translated into something a senior engineer would consider building. With timeline ranges, cost ranges, scope, risks and the question "does this actually want to exist?" answered honestly. Sometimes the honest answer is no, and that's worth knowing before €40k disappears.

Once the concept document is signed off, the build follows the spec. Stack selection happens deliberately — Laravel + Filament for the backend and admin, Next.js or Vue on the front, Postgres or MySQL for data, Cloudflare and a hardened VPS or AWS for infrastructure. The choice depends on the concept, never on which framework I happen to feel like that month. The full design system gets built, the codebase gets owned by you from day one, and the server is set up to grow with the product instead of needing replacement at the first traction. Testing is in the budget. Scalability is in the architecture. Monitoring, backups, SSL, mail delivery — all live in the same one-person, end-to-end view that started with the rough idea. Nothing in this process gets handed off to a different team that doesn't share context.

I prefer to work on concepts where the relationship lasts past go-live. Not because of recurring revenue — because the second version is almost always better than the first, and it's a waste to hand the second version to a stranger. After launch we keep going: monitoring, security patches, the new feature your users keep asking for, the integration that turned out to be necessary, the rebuild of the one part that needs rebuilding once you have real data. In practice this means most of my client relationships are multi-year. Some founders have been with me from idea to v3, with the same person making the technical choices and remembering why they were made. That continuity is part of the product — it's the difference between software that compounds and software that gets stuck waiting for the new contractor to read the codebase.

By quote — because the right price depends entirely on what your concept actually is. A focused B2B tool that goes live in 8 weeks lands in a different bracket than a full SaaS platform with billing, admin, mobile and integrations. After the strategy call you get a written concept document that includes a fixed-price quote for the build (or a fixed-price-per-phase if the project is genuinely too big to commit to up front). Fixed price is possible — preferred for clean-scope projects. Hourly is also possible — sensible when scope is genuinely going to evolve as we learn from real users. Either way the budget is honest, the milestones are written down, and the post-launch retainer is agreed before we start. No mid-project surprises, no "and one more thing" invoices.