I’m Challenging Myself to Build a Product with AI — Here’s Where I’m Starting

Navid Hosseini — Thu, 09 Jul 2026 20:31:55 +0000

I've been a software engineer for over 15 years. I've worked across companies of very different scales - from scrappy startups to large organizations - and I've touched most corners of backend development along the way. A few years ago, I took a real swing at running my own business with some friends. We gave it three years. It didn't work out.
That experience left its mark. Not in a bitter way, but in the way that failure tends to clarify things. I understood what I was capable of, where we fell short, and - most importantly - that the drive to build something of my own never really went away.
Four years ago I moved to the Netherlands. And something shifted. The ecosystem here, the density of opportunity, the culture around entrepreneurship - it made me think: maybe the conditions are different now. Maybe I am too.
But there's another thing that's genuinely different this time: AI.

The Busy Person's Bet
I have a full-time job. I have a family. I am not a 22-year-old with unlimited evenings and nothing to lose.
For a long time, that felt like the argument against trying again. Too much on my plate. Not enough hours. But watching how AI tools have evolved - not just as code assistants, but as thinking partners, research tools, and force multipliers - I started to see it differently.
What if the era of AI agents actually levels the playing field for busy people? What if you no longer need a full co-founder team, a dedicated DevOps engineer, and 60-hour weeks to go from idea to product?
I want to test that hypothesis. On myself.
So I'm challenging myself: with a full-time job, a family, and whatever hours I can carve out, I'm going to build a real product - using AI as a core part of the development process. Not to replace my engineering judgment, but to amplify it.
This series of articles is the documentation of that journey. The decisions, the failures, the surprises, and the lessons. Honest and in public.

The First Idea: A Crypto Payment Gateway
My first project is building an open source crypto payment gateway. This isn't my first time working with blockchain - I have hands-on experience in the space - but it's the first time I'm building something end-to-end on top of it as a product.
The idea is straightforward: merchants should be able to accept crypto payments without trusting a closed-source black box. Most existing solutions are either opaque commercial products or under-maintained open source projects that haven't kept up with the modern regulatory landscape.
In the EU, MiCA (Markets in Crypto Assets regulation) is creating a clearer, more legitimate framework for crypto businesses. That's actually an opportunity - a well-architected, compliance-aware, open source gateway built for this new environment doesn't really exist yet. I want to build it.
The gateway will handle crypto wallet operations, payment requests, merchant management, webhooks, and a merchant-facing dashboard. Think of it as the Stripe of crypto - minus the black box, minus the vendor lock-in.

Architecture: The Short Version
Let me be upfront about something: this is a polyglot stack. Go, PHP/Laravel, and Next.js - three different languages, three different ecosystems, three different mental models.
Not long ago, a setup like this would have required at least three engineers: a Go developer for the wallet service, a PHP/Laravel specialist for the backend, and a JavaScript engineer for the frontend. Each living in their own world, needing coordination, cross-language code reviews, and constant context switching at the team level.
I'm going to attempt this alone - with AI as my co-engineer across all three stacks. That's the real experiment embedded inside this project. Not just "can I build a payment gateway," but "can a veteran software engineer, acting as an AI orchestrator and conductor, cover the ground that used to require a whole team?"
I genuinely don't know the answer yet. But that's what makes it worth doing.
Here's the shape of the system:
Wallet Service (Go) - The most security-critical component. Handles blockchain interactions, transaction signing, and key management. Go was chosen for its concurrency model, low memory footprint, and culture of explicit error handling - all qualities that matter when you're writing code that touches money.
Backend & Back Office (Laravel) - The business logic layer. Merchant management, payment flows, webhooks, reporting, and admin tooling. Laravel's maturity and rich ecosystem make it a solid choice for this kind of workflow-heavy service - and it has a strong open source community, which matters for a project that invites contributors.
Customer Panel (Next.js) - The merchant-facing dashboard. Next.js for performance, server-side rendering, and accessibility to frontend contributors.
Each service has its own database and cache - no shared state between services. They talk to each other via APIs.
On the repository side, I chose three separate GitHub repos over a single monorepo. The main reason is that the wallet service has different security and access requirements than the other two - it's the kind of code that benefits from tighter ownership and a cleaner audit trail. A fourth lightweight repository acts as a local development orchestrator, wiring all three services together with Docker Compose so any contributor can spin up the full stack with a single command.
I won't go deep into the architecture decisions in this article - that's coming in future posts. But that's the shape of it.

How I'm Using AI in This Project
I want to be specific about this, because "building with AI" can mean a lot of things.
I'm not using AI to generate code I don't understand and ship it blindly. I'm using it as a collaborator - someone to think out loud with, pressure-test decisions against, and accelerate the parts of development that don't require my specific judgment.
The architecture I described above? I didn't design it alone. I had real back-and-forth conversations about monorepo versus polyrepo, about whether certain frameworks were the right fit, about Docker Compose structure for a multi-repo open source project. AI helped me get to better answers faster than I would have alone - not because it's smarter, but because having a knowledgeable partner available at 11pm, after the family is asleep, is genuinely valuable.
That's the bet. And so far, it's looking interesting.

What This Series Will Cover
I'm treating this like a journal as much as a technical blog. Future articles will cover:
Setting up each service from scratch - structure, decisions, and tradeoffs
How I'm using AI agents for different parts of the development workflow
The business side - thinking about positioning, compliance, and what "open source with a commercial future" might look like
The honest parts - where things took longer than expected, where AI fell short, where I second-guessed myself

Speaking of commercial: I'm keeping all repositories open source, at least for now. It's important to me that this project contributes something real to the community, not just lives in a private repo. In the future, some modules - particularly around the wallet service - might move toward a commercial model. But that's a bridge I'll cross when I get there. For now, everything is open.

A Casual Job, Not a Startup Sprint
I want to be clear about the pace. This is not a "quit my job and go all-in" story. This is a side project that I treat like a second job - a casual one. I'll spend time on it when I can. Some weeks that will be a few hours, some weeks more.
The goal isn't speed. It's consistency and learning. I want to ship something real, build a network around it, and deepen my engineering knowledge - particularly on the infrastructure and compliance side of blockchain, an area I've worked with before but never taken this far from scratch. And honestly - prove to myself that the entrepreneurial side of me that showed up during that three-year run with my friends isn't gone. It just needed better conditions.
The Netherlands feels like better conditions. AI feels like a better toolkit. Let's see what's possible.

If you're a busy engineer with your own ideas that keep getting pushed to "someday" - I hope this series is useful to you. Follow along, and feel free to challenge anything I do in the comments. That's how this gets better.

DEV Community: Navid Hosseini

I’m Challenging Myself to Build a Product with AI — Here’s Where I’m Starting