What happens when you skip the whiteboard
As a founder / developer, building something from scratch, what would I do differently if I could build Unscript IKIGAI® now?
Work out the architecture on paper / whiteboard, like in good old times of the past. I moved my scattered ideas and work from Bolt to Claude, without proper sanitizing the code, the logic, the prompts, the data architecture. It looked like a lateral move (cue - it was not), and I thought it would work easily. It cost me a lot of tokens to update the logic later, and hours of debugging.
Data architecture and security - I built it, I tested it, I even shared with a few friends as an early access, and all looked great. Until at some point I was checking someone’s record in the database and realized that I can actually see their answers.
That made me cringe - if I was a user, I would not want ANYONE have a possibility to see what personal information I shared. So I had to re-develop the whole approach - investigate how I can encrypt the data at rest and in transit, what are the functions for postgres in supabase that can be used (there are two approaches, and I will try the second in the future), what functions need to be written, how do I encrypt existing user data (mind, there were 3-4 users at the time but I still wanted to make sure everything is as robust as possible). Headache - yes, peace of mind - also yes and I spare myself blushes.
It was also a recommendation from Jasmine Vincent to specify this on the home page - that the data is fully encrypted and is never exposed as plain text - to make sure users know their inspiration and ideas are safe. If you made an effort on going above and beyond on data privacy and security, own it - and place it on the homepage. It can be a differentiator amongst those who don’t care as much.
If you are building something for fun (or as a potential business idea): start with data architecture and security. Modern databases do offer you security tools as part of the project details, but sometimes it makes sense to go one level deeper than just RLS (Row Level Security). Build the structure of your solution on paper, iterate with your development agent, drill on what specific terms mean. Coding Agents are generally good, but often dismissive, thus questioning their decision making on the prompting stage is my habit now.
Always think about user experience - not only from the UX perspective, but also their confidence. If I trust this person with my data, is it safe? Even more so with agentic implementation, think the same way - will the agent do as described, or can it become a liability - prompt injection, over-scoped OAuth tokens, both well-documented risks that most builders ignore until it is too late? On top of all that, I bought a cybersecurity insurance - punchy, but made my sleep better.
When I was about to launch it publicly, my friend and ISO auditor Elena Bobkova, J.D., LL.M. (who is writing about all things AI Security, Data Security etc, on top of cool projects like chicken coop data automation), posted about the AI Agents monitoring business ideas, and the need to protect yourself from plagiarism and copyright infringement.
I instantly went to Claude to do the full audit of my code, the prompts, the visualization, and found some critical exposures, some medium risks, and luckily - a lot of green lights too. I was not THAT bad in the end 😊
| What it strips | Why it matters |
|---|---|
<script>...</script> | Prevents code execution |
<style>...</style> | Prevents CSS-based attacks |
on*= event handlers | e.g. onclick=, onload= |
javascript: in links | Prevents click-to-execute links |