People often ask me — how did you build this? Where did you start? How long did it take? This is my honest answer.
NoteToMail didn't appear overnight. The idea had been sitting in my head for almost two years before a single line of code was written. And even then, the journey from first commit to a working product was longer, harder and more rewarding than I expected.
Like most product ideas, NoteToMail came from a problem I experienced personally. After every meeting, I found myself staring at a page of notes trying to turn them into a clear, professional follow-up email. It was repetitive, time-consuming and frankly tedious.
I thought — surely AI can do this. But when I looked around, nothing quite did what I wanted. There were meeting transcription tools, AI writing tools, note-taking apps — but nothing that took your raw notes and produced a proper email, ready to send.
So I decided to build it.
"The idea sat in my head for nearly two years. The hardest part wasn't having the idea — it was deciding to actually build it."
My first instinct was to dive straight into code. But I've seen too many projects fail because the builder started coding before they understood what they were building.
So I stopped and spent serious time on design first. Not just the visual design — the product design. What does the user experience look like? What are the core features? What are the edge cases? What could go wrong?
I drew architecture diagrams. I mapped out every page. I thought through what happens at each stage of the user journey. Only then did I start building.
Before you write a single line of code, build an architecture diagram. Map out every page, every feature, every data flow. The time you spend planning will save you ten times that in rework later.
One of the most important early decisions was choosing which AI model to use. This isn't a trivial choice — different models have different strengths, costs, speed profiles and context window sizes. The wrong choice early on can be very expensive to undo.
I spent a lot of time evaluating options, testing outputs, and thinking about what NoteToMail actually needed. Transcription accuracy. Multilingual capability. Email quality. Analysis depth. Each requirement pointed towards different solutions.
Eventually I settled on a combination that balanced quality, cost and reliability. But getting there took real experimentation — not just reading documentation.
Don't just pick the most popular AI model. Test several. Think about your specific use case — accuracy, speed, cost, language support. The right model for someone else may be the wrong model for you.
Once the architecture was clear and the model chosen, building started. And that's when all the things you didn't think of start appearing.
Some examples from our journey:
Each of these features added time. Some took days. Some took weeks. And new edge cases kept emerging even after we thought a feature was done.
Every feature you add will take longer than you think. Plan for the edge cases, not just the happy path. The things you don't expect will consume more time than the things you do.
We redesigned the interface multiple times. What looks good on a desktop doesn't always work on mobile. What makes sense to a developer doesn't always make sense to a first-time user.
We tested on different devices, different screen sizes, different browsers. We watched people use it and changed things based on where they got confused. We changed the layout, the wording, the colours, the flow.
This iterative process is frustrating but essential. A product that doesn't get used isn't a product — it's a portfolio piece. Making it genuinely easy to use is non-negotiable.
Ship early and iterate often. Don't wait for perfect — get it in front of real users as soon as it works. Their behaviour will teach you more than any amount of internal testing.
When you're building your first product, you have to be smart about costs. I'm not a VC-backed startup — I'm a founder spending my own money. Every pound counts.
We spent time researching hosting options, database solutions and infrastructure costs. We chose tools that could scale when needed but didn't cost a fortune to get started. Vercel for hosting. A managed database that gave us what we needed without over-engineering.
The temptation is always to over-architect. To build for a million users before you have ten. Resist it. Build for where you are now, with a clear eye on what you'll need to change when you grow.
Don't over-spend on your first product unless you have the resources to do so. Choose infrastructure that is good enough to launch and scale when needed. Keep your running costs as low as possible while you find product-market fit.
Building the product is only half the job. The other half is getting people to use it.
Choosing a domain name, building a marketing website, writing copy that explains what the product does clearly and compellingly — all of this takes time and thought. We went through several domain options before settling on notetomail.com. We redesigned the landing page multiple times. We wrote and rewrote the copy until it felt right.
And then we launched. And kept iterating.
If someone came to me today and said they wanted to build an AI product, here's what I'd tell them:
NoteToMail is live today. It works. People are using it. And we're still improving it every week.
It took hard work, long hours and a lot of patience. But it was worth every minute.
"The main thing is — don't just have an idea in mind. Have a design, have a product in mind, think about various things before you actually go and build."
Satyajit Singh is the co-founder of SafalSolutions Ltd, a technology company based in Reading, UK. NoteToMail is their first AI product. safalsolutions.co.uk