From engineer to founder: how we sold a “SaaS” that was actually a PDF (and we’re still dancing)
We sold our SaaS product without having anything built. Just like that.
We wanted to create a financial reporting product but:
- There was no infrastructure
- There were no repos
- There was no database
In fact, there wasn’t even a chosen “stack”. And yet, we secured our first clients.
With nothing in place, we had already made a promise to the market and set a delivery date: within a month and a half our first users had to receive value.
The “product” at that point? A handmade monthly PDF with financial insights.
We had promised software. A platform. And our main problem, the one driving everything forward, was replacing that PDF with a dashboard before the train ran us over.
This is the story of my first tango as a technical founder: moving from leading teams and making engineering decisions to building a product from scratch while making business decisions with two resources constantly slipping through your fingers: time and money.
In our previous stages, working closely with consultancies and agencies, we began to notice a recurring pattern: they focused heavily on delivery but had very little financial visibility. And in businesses where margins are tight and work is mostly project-based, that is fundamental if you don’t want to lose money.
In “mid-sized” companies (the typical ones already billing well, but not enough to justify a finance department), having a dedicated finance profile didn’t make sense. And yet the need was there: understanding the real margin of each project, forecasting cash flow, deciding when to hire, when to slow down, how much to invest, or identifying which clients are draining your energy and profitability.
That’s when we started asking ourselves whether it made sense to build a system that filled exactly that gap: a sort of accessible financial management function, connected to your tools, translating numbers into the language of the business, and helping you make decisions without having to become an expert.
That’s when we created Sherpa.
Sherpa Platform aimed to:
- 💰 Automate data processing: consolidate bank statements, integrate accounting information and generate reports without relying on Excel spreadsheets.
- 📈 Generate dynamic and personalised reports: deliver clear reports tailored to each client’s needs without consuming hours of manual work.
- 🔢 Manage projections and KPIs reliably: analyse data in real time, minimise errors and provide financial decisions based on solid information.
On paper, it all looked great.
Taking the first steps with the Wizard of Oz
I hadn’t “written code” in a few years.
My professional career had moved towards managing engineering teams, so my development skills were, at best, a bit rusty.
In my final stages as a developer, I had worked extensively with JavaScript, mainly Node in microservices platforms and some React for frontend, with Azure as infrastructure.
Now I had to build a financial platform and I had nothing but a blank canvas.
We started in the way every lean startup framework recommends: validate before building and keep validating while you build.
Our validation came through a PDF. We delivered a PDF to our first client and it met every expectation.
We couldn’t have a fully developed product covering all user needs automatically, but we could manually produce a monthly PDF deliverable for our clients.
The Wizard of Oz technique is precisely about that: validating a product or service idea by manually simulating how it works behind the scenes (like a hidden “wizard”) in order to learn quickly from the customer without building all the technology.
Of course, we still had to build a minimum layer of technology, at least to access our clients’ banking and accounting information. And above all, we had to build it very quickly.
And here came the first major trade-off: we chose our stack by prioritising speed above everything else, fully aware that we would pay for it later.
- 🏗️ Vercel to deploy in minutes and move fast
- spoiler: serverless doesn’t get on well with heavy ingestion processes.
- 🧑💻 NextJS because it fit perfectly with Vercel and allowed us to move forward without setting up APIs at the beginning
- spoiler: the portability of a monolithic Next app into something distributed is virtually non-existent if you don’t clearly separate frontend and backend.
- 🗃️ Supabase as managed Postgres, avoiding strong vendor lock-in (JWT auth instead of “out-of-the-box”).
- spoiler: this time we got it right.
- 📜 Cursor as an AI-powered IDE: for someone with strong high-level concepts but slightly rusty, it acted as a co-pilot that reduced friction.
And that’s how our tango began. In less than a month and a half, we managed to build a web application that consisted of nothing more than a landing page, a login and an integrations window.
During onboarding, the integrations section allowed the user to:
- Enter a Holded API key so we could retrieve their accounting information.
- Enter their banking credentials so we could access their banking data via the API of a service we had contracted (in this case, GoCardless).
Once onboarding was complete, the user could no longer interact with the application, but in our database we had all the information needed to manually prepare the PDF reports.
We started to feel a bit “Tangled up”
As our client base grew, we realised that not only did we need to gradually replace the PDF with application features, but new integration and scaling requirements were also starting to appear.
I learned then that the founder’s role requires, among other things, the ability to manage the most valuable resources of any startup: time and money.
We decided to invest money to bring in a couple of wizards to save us time — this time not from Oz, but from our own network.
That’s when we found ourselves dealing with two major fronts at once:
- On the one hand, adding features to the application to finally bury the PDF.
- On the other, improving the system and its scalability to handle more clients, more integrations and more data.
We were like Buster Keaton in the famous scene where he has to clear the train tracks while the train keeps moving forward without stopping.
“Just tango on” with a couple of software wizards
This is when the tango became intense and interesting. Do you remember the spoilers above? Let’s revisit them and see how we dealt with them.
⏱️ Serverless + heavy ingestion = bad combination.
If you need to process large amounts of background data in a serverless environment, you’re in trouble. Vercel functions have a specific timeout depending on the plan, but they are still functions with a “cold start” that spin up to execute a task and then shut down once it’s done.
Imagine running a data ingestion from an ERP (Holded in this case) and having to deal with a five-minute timeout. However efficient your code is, if you process data from 10 different users at an average of 30 seconds each, you hit the timeout.
To solve this, we decided to use a workflow service called Inngest. That allowed us to execute each ERP ingestion in isolation as a “step” within a flow.
⚒️ New providers = your model wasn’t as agnostic as you thought.
We began experiencing limitations with the provider we were using (GoCardless) to connect to our clients’ bank information. So we decided to offer another one: WealthReader.
Some clients also asked us to integrate with another ERP besides Holded: FacturaDirecta.
That’s when we realised that our data model wasn’t as agnostic as we had believed. Entities such as Invoices, Bank Accounts and Transactions were tightly coupled with the data models of Holded and GoCardless, and we weren’t ready to simply “plug-and-play” WealthReader and FacturaDirecta.
We embarked on a substantial refactor of the entire data model and the integration functions with external sources.
🔮 Meanwhile, the train didn’t stop.
The phrase we repeated most at the time was: “this doesn’t scale”.
We were coming to terms with the idea that at some point we would have to migrate everything to a solid cloud provider: saying goodbye to Vercel and serverless, to Supabase, to Inngest and, above all, to NextJS.
So we began preparing the ground (once again, with the PDF as the common enemy):
- From then on, we would only use endpoints to maintain a clear line of separation between frontend and backend.
- We defined a better architecture to distribute responsibility across different backend services, with adapters to integrate third parties (Holded, FacturaDirecta, GoCardless, WealthReader).
- We built each frontend component with the clear intention of being able to isolate it into a standalone frontend service in React.
What the dance floor has taught me
You dive into entrepreneurship as a technical founder and there’s no parachute. You simply have to make things work, again and again. There’s no room to even consider the perfect solution because you live in a continuous process of searching for and refining the problem you’re trying to solve.
The only thing that matters is speed of reaction and the ability to face the next challenge, but it’s important to try to anticipate where the next bottleneck will appear, because at least you can take actions to mitigate its impact.
In the end, it’s about constantly seeking balance between current technical debt and the debt that may materialise in the future, because thinking you can build something while completely avoiding it is somewhat naive.
The concept of “trade-off” regarding technical debt applies even more strongly to the two most valuable resources of any startup: time and money. You can take on all technical tasks as a founder at the cost of time, or you can delegate some of them to people with stronger capabilities at the cost of money.
And finally, the most valuable resource you can have, and always will have, is your network. Picking up the phone to rely on either of the two wizards mentioned above has a value that is impossible to quantify.o quantify.
Want to know a little more about who wrote this article? 👇
I have spent years building products and systems (a great deal of backend, microservices and cloud). I have worked in consultancy, led teams and international projects, and also experienced the pace of a startup from the inside as technical co-founder at Sherpa until exit. I now help companies at Orbitant grow through solid engineering, innovation and practical thinking.