Building a B2B fiscal platform in 10 days: what we did and what we cut
Ten weeks of 10-hour sprints. Solo founder. Four products (PDF, VeriFactu, FacturaE, Extract) targeting a regulatory deadline then set for January 2027. Here's what the actual process looked like, what decisions accelerated things, and what we cut without ceremony.
The context
Kreyo is a solo-founder project. The constraint is time: roughly 10 hours a week of focused development, the rest going to a day job. The opportunity is structural: Spain's VeriFactu regulation mandates that every business register invoices with AEAT in real time, a date now planned for October 2028 (pending regulatory approval). Every ERP, every TPV, every accounting platform serving the Spanish market needs to either build this or buy it.
That's a large market with a hard deadline, the kind of situation where a focused API product can get traction before the incumbents finish their enterprise sales cycles. But only if you ship something real before the market conversation starts, which means now, not Q4 2026.
The target was: four working products, production API, docs, landing pages, billing, authentication, all in ten weeks. In total, roughly 100 hours of development time across the whole stack.
The decisions that accelerated
AI-assisted development with Claude Code
The single biggest productivity multiplier was using Claude Code (Anthropic's CLI-based coding assistant) for implementation after planning in Claude Desktop. The workflow that worked:
- Write a detailed spec for the feature or component in Claude Desktop (natural language, covering requirements, edge cases, and the shape of the solution).
- Hand the spec to Claude Code in a fresh session and implement iteratively.
- Review, test, and correct — the human's job is judgment, not boilerplate.
The spec-first approach pays off more than it seems upfront. A 2-hour spec session typically produces a 4–6 hour implementation session that would otherwise take 12–15 hours with context-switching and rethinking. The spec forces clarity that the code then inherits.
Conservative, boring stack
.NET 9, PostgreSQL, Redis, Docker. No microservices. No message queue. No event sourcing. The API is a monolith that does exactly what it needs to do: accept requests, process them, respond.
The boring stack choice was intentional. Every hour spent on infrastructure configuration is an hour not spent on the fiscal compliance logic, which is where the actual value is. Redis for rate limiting and idempotency keys. PostgreSQL for everything persistent. Docker for local dev parity. Done.
Static HTML without a JS framework
Landing pages, blog, and documentation are static HTML served by ASP.NET Core's
UseStaticFiles. No React, no Astro, no build step for the marketing site.
A page is a file. A change is a file edit. Deploying is pushing to the container.
This sounds extreme until you realize how much time framework setup, bundler configuration, and hydration debugging would have consumed. For a content-heavy site with moderate interactivity (a lang switcher, a filter chip on the blog listing), vanilla HTML and 200 lines of JavaScript is the right level of abstraction.
Shared components across four products
Authentication, API key management, rate limiting, billing integration, certificate handling, NIF
validation — all built once and used across all four products. The shared InvoiceData
schema means each product doesn't re-invent how an invoice is described.
Building four products sounds like more work than building one. It's only more work if the four products share nothing. When they share 60% of their infrastructure, building four takes maybe 2× the effort of building one — not 4×.
What we cut without ceremony
No UI. Covered in a separate post. The short version: ERPs have their own UI. Building one for them would create a competing surface, not a complementary one.
No assisted onboarding. The docs are the onboarding. If the docs are good enough that a developer can start integrating without a call, the onboarding is done. The first human touchpoint happens when they hit a question the docs don't answer — which is when it's most useful.
No initial marketing. Blog-first instead. SEO takes time; better to start with content that will compound than with campaigns that stop the moment you stop paying. The blog posts that explain the domain are the marketing.
No single-product focus. The counter-intuitive decision was to build four products instead of one and iterate. The reason: the compliance pain in Spain is multi-dimensional. A customer who needs VeriFactu also probably needs PDF. If you only offer one, they integrate two vendors. If you offer four, the integration surface shrinks. Breadth at launch is a feature for this particular market.
What I learned writing specs before writing code
Every feature that got a proper spec before implementation was faster than every feature that didn't. This sounds obvious stated baldly, but the temptation to "just start coding" is constant when time is scarce. It's wrong. A 30-minute spec session prevents a 3-hour debugging session.
Specs for this project weren't formal documents — they were long prose descriptions in Claude Desktop that covered: what the feature is, what the inputs look like, what the outputs look like, what the error cases are, and what the tradeoffs are. That's enough. Formal spec tooling is overhead.
The spec also serves as the first draft of the documentation. When you've articulated what a feature does in plain language, turning that into API docs is mostly editing, not writing.
What didn't work
Testing against AEAT's preproduction environment before the account was activated. The AEAT test environment requires a registration process with a waiting period. Starting that process early is worth it — being blocked for two weeks while waiting for credentials is a predictable setback that isn't obvious until you've experienced it.
Assuming the FNMT CA would be trusted by default. The certificate authority that issues Spanish tax certificates (FNMT) is not in the default trust store of major cloud providers. This caused mTLS handshake failures that looked like network errors until we identified the root cause. The fix is simple once you know what it is; getting there cost half a day.
Where things are now
The API is in production. All four products are working. Docs are live. The blog you're reading is part of the content strategy. The open-source components (NIF validator, hash calculator) are published.
The next phase is customer acquisition — outreach to ERPs and TPV manufacturers, showing up in the conversations that happen as VeriFactu's mandatory date approaches. That's a different kind of work, and it runs in parallel with continued technical development.
The constraint hasn't changed: roughly 10 hours a week. The advantage is that the platform is now built, which changes the marginal cost of new features from "significant" to "low".