invoo: From Idea to Multi-Platform Product

Spanish freelancers waste 15+ hours a year on invoice admin that should take minutes.

I co-founded a tool that cuts invoice creation to 15 seconds. Then I built a native mobile app in 8 days to put it in their pocket.

150+ people signed up before the product launched. Zero ad spend. Web, mobile, and a shared backend, shipped publicly on May 5, 2026.

AEAT announced mandatory digital invoicing. I saw an opportunity.

Spanish freelancers and small businesses already hate compliance. Now they would be forced to use invoicing software. The existing options were painful.

I spent weeks reading X posts and Reddit threads. The pattern was clear: tools complied with regulations, but they tried to do everything and did nothing well. Cluttered interfaces. Confusing workflows. Features nobody asked for.

Worse, competitors charge users to connect with accountants. Freelancers feel this pain most, but small businesses have the same problem: create an invoice fast, know the tax is correct, and connect with your accountant without paying extra.

Nobody was focused on that.

And none of the competitors offered a real mobile experience. Freelancers invoice from job sites, cafes, and client meetings. They need native speed, not a responsive web page.

We made three bets across the life of this project.

First, speed over perfection. I owned everything user-facing while my co-founder handled backend. No handoffs, no waiting. When I spotted a gap, I fixed it that afternoon.

Second, we pivoted our tech stack mid-build. We started with React and Next.js, but discovered security gaps and realized that switching to Angular and Java would let us apply as an official AEAT API provider. That pivot cost us a month.

Third, the mobile gap I spotted during research was too big to ignore. None of the competitors had a real native app. Freelancers invoice from job sites, cafes, and client meetings. A responsive site would never match the speed of native haptics, context menus, and offline-ready architecture.

I chose React Native with Expo to share the existing Spring Boot backend while delivering a truly native feel.

The go-to-market was simple: listen, help, convert.

I spent the first weeks in freelancer communities on social media, tracking the tax questions that kept appearing. Then I wrote guides that solved those exact problems and posted them back to the communities where I found them.

No pitch. Just value.

That content drove traffic to the blog. Visitors found more helpful articles and a waitlist signup. By the time we announced the product, we had already helped hundreds of freelancers.

While the blog built the audience, we built the web experience. Once the platform was nearly complete — database, endpoints, core flows all in place — I turned to mobile.

The market gap was clear from day one — no competitor had a native experience — so I went all in. 8 days. 40+ commits from initial scaffold to feature-complete. Five core tabs: Dashboard, Clients, Catalogue, Expenses, and Settings.

The app shares the same Spring Boot backend and authentication with the web version.

Two pivots. Both right. Both avoidable.

We started with React and Next.js, then realized we needed Angular and Java to qualify as an official AEAT API provider. That cost us a month. If I had mapped the regulatory requirements before choosing a stack, we would have started there.

Same story on mobile. I built the first version with Ionic, but the transitions and gestures felt off. I switched to React Native and the difference was immediate. I should have trusted my gut earlier — if native feel matters, go native from the start.