Building Lumio: my first personal SaaS from idea to launch

I have spent most of my career building software for other people.

That is not a complaint. Freelance work, contracts, and employment taught me things that are hard to learn any other way. You build under real constraints, for real users, with real consequences when things go wrong.

But there is a category of lesson you only get by building something entirely your own — where you make every call, live with every decision, and cannot hand the hard parts to a product manager or a client spec.

Lumio is my first personal SaaS. This is the honest account of how it got built.

Where the idea came from

The problem is simple to describe: reading a dense PDF is often slow and frustrating, especially when you hit unfamiliar concepts or technical language.

The existing workflow for most students is: read something confusing, open a new tab, search for an explanation, lose your place, and repeat. That friction adds up fast across a long document or a study session.

The idea was to collapse that loop. You highlight the text you do not understand, and an explanation comes back immediately — either as text you can read or audio you can listen to while staying on the page.

The target user is a student or early professional in a market like Nigeria where access to quality tutors or explanations is limited but smartphone and internet access is real. That context matters for the product decisions.

Deciding what the first version had to do

Before writing a line of code, I spent time being honest about what the product needed to do well on day one versus what could wait.

The core loop had to be tight:

• upload a PDF
• read it on screen
• highlight text
• receive an explanation

That is the whole product, at minimum. Everything else — history, audio playback, search, document organisation — is useful but secondary.

The temptation with AI-powered products is to reach for every capability immediately. Summaries, chat interfaces, quizzes, flashcards. I kept pulling myself back to the one thing that made the product real: highlight and understand.

That constraint made the first version better.

Designing the system before writing code

I did something on Lumio that I have not done as deliberately on other projects: I wrote a full system design document before building anything.

Not pseudocode. An actual architecture document that covered:

• the component breakdown and how they communicate
• the data model, including the pgvector schema for semantic search
• the SSE streaming architecture between Laravel and Node.js
• the ElevenLabs TTS integration for audio output
• the queue design for processing jobs

This took longer upfront and saved significant time later. When the architecture is written down and challenged before it exists in code, you catch design problems cheaply. When you find them mid-build, you pay in rewrites.

The key architectural decisions:

Laravel handles the stateless work. Authentication, user data, PDF ingestion, AI call dispatch, queue management. Laravel is good at all of this and I know it well.

Node.js handles the SSE connections. This was a deliberate choice based on hard experience. PHP-FPM worker pools are not designed for long-lived connections. Node.js's event loop holds thousands of open connections cheaply. The two services communicate through Redis pub/sub.

pgvector for semantic search. PDF content is chunked, embedded, and stored in PostgreSQL with the pgvector extension. This allows the explanation engine to find relevant context from elsewhere in the document when generating a response — not just the highlighted passage in isolation.

ElevenLabs for audio. Text-to-speech through ElevenLabs gives the audio output a quality that built-in browser TTS cannot match. For a product aimed at learners who may want to listen rather than read, this matters.

What building your own product feels like

There is a specific kind of discomfort that comes with building something you own entirely.

On client work, someone else set the priority. On employment, there is a roadmap. On your own product, every week you have to decide what matters most — and live with the fact that you might be wrong.

I spent time early on second-guessing the stack. Wondering if the market was right. Worrying that the idea was too simple or not differentiated enough.

What got me past that was shipping. Not shipping a finished product — shipping a version I could look at, use, and show to someone. Once the loop worked and I could highlight a sentence in a real PDF and see an explanation come back, the doubt cleared.

The product exists. That changes the conversation from theory to feedback.

What I would do differently

A few things I would adjust:

Write the spec earlier and in more detail. I did this reasonably well on Lumio but I have built enough projects to know I could go further. The more precisely the system is described before it is built, the fewer decisions you have to make under pressure mid-build.

Pick the audio feature as the primary differentiator from day one. I treated text and audio as equal outputs initially. Looking at the target market, the audio explanation is the feature that is hardest to replicate with a quick Google search. It deserved more emphasis sooner.

Do not skip onboarding. I underestimated how much work good onboarding is. Getting someone to their first successful explanation in under two minutes is a product problem, not just a UX detail.

What comes next

The core product is live. The work now is getting it in front of the right users, listening to what they do with it, and improving the parts that create friction.

The features I am watching most carefully:

• document organisation and history
• explanation quality on highly technical content
• mobile reading experience

If you are a student or work in a context where you read a lot of PDFs, I would genuinely welcome you trying it. You can find it at lumiodocs.com.

And if you are a developer building something for the first time — building your own thing, with your own name on it — the discomfort is part of it. Build the thing. Ship the version that works. The rest follows.