I Built (and Launched) a Product in 2 weeks

Melchor Tatlonghari

There is undoubtedly an AI boom in the tech industry today and I wanted to see how complex it would be to build an application from scratch. The scope was fairly simple: a user uploads a PDF document, the AI reads the document and provides a set of results. Simple… Right?

The value proposition was to simplify hundreds of pages of PDF files into a couple of bullet points that people could understand. Insurance companies give us hundreds of pages of PDFs to read through when we sign up for coverage, but nobody really reads through them. The pain point, however, comes when we actually have to make a claim and we are blindsided by technicalities and loopholes. And so, the product idea was born.

That’s the overview of the product. Let’s dive right into the lessons.

Lesson #1: Do not build everything from scratch

Engineers have a habit of building, and for good reason: we love it! The state of flow when we are coding is a high that many engineers know and love. The problem arises when you are building your own product without a Product Owner or Team Lead to give you boundaries on what to build or not. It’s easy to fall into that rabbit hole of unending scope creep.

More often than not, I hear engineers supposedly building an MVP who have been coding for months (or even years): “Just one more feature”, “Just one more tweak”, until the potential market has already moved on and the idea has gone stale.

Learn to leverage what is already available and focus on your key value proposition. Do not reinvent the wheel; make use of products that will help you accelerate your build.

I knew my application’s key value proposition, but there were still several plumbing tasks that needed to be done. An example of this is my application needing a way to take payments from customers. However, I wouldn’t go about building something that has already been built a thousand times by someone else. Below are the tools and software I leveraged:

• Payments API — Stripe
• Infrastructure — Heroku + AWS Amplify
• UI Components — SVG Repo + Lottie + Unsplash

I have to admit, it was surprising to see how much time it took to integrate with some of the 3rd Party Applications, but imagine the time it would take if I had to build everything from scratch.

Lesson #2: The biggest expense is the domain name

As a fairly senior engineer, I was able to leverage a mostly serverless architecture. I have a library of Infrastructure as Code that I could rely on, which made things a lot easier. I managed to get my application’s cost down to only $1-$2 a month depending on traffic. And when no one is using my application, it doesn’t cost anything.

However, I was surprised that there was no way to avoid purchasing a domain name. I couldn’t find a way to buy a temporary domain name just to test my idea! No matter how good your idea is, users won’t be clamoring for your site if you’re using an auto-generated URL from Heroku like https://boiling-sands1-123214123-123.herokuapp.com. It instantly diminishes your credibility.

Now, depending on how good your domain name is, the price range could go up thousands of dollars per year. I wanted to name my application TaCai, meaning Terms and Conditions Artificial Intelligence. I had built all my code around using TaCai, only to be surprised at the cost when I was about to deploy. The good thing was that I had parameterized it, so swapping it out was easy. I ended up settling with: Insurance Policy AI: https://www.insurancepolicyai.net, but I can imagine a more junior engineer being blindsided by this and having to rework a lot of their code, as no one really expects a name to cost so much.

Original domain name I had in mind. Couple of more constraints I learned:

Domains are sold per year — There is no way to just hold a domain name for a couple of months to test an idea; you have to commit to a year. People buy domains even if they have no applications in mind — https://www.insurancepolicyai.com has already been sold to someone else, and I would have to buy it from them if I really want that name.

Lesson #3: It really pays to be Agile

Remember, being busy doesn’t mean being productive.

I have worked with countless big corporations (check my Linkedin), and for the longest time, I followed the Agile mindset (I say mindset because some people follow the methodology but do not understand the underlying principle), but I never really appreciated its value.

I had set up my own mini Sprint Board, and every morning for my solo “stand-up,” I would assess what would deliver the most impact and set up the tasks I needed to accomplish for the day. Anything that comes to mind or any task that pops up, I quickly add it to my board and focus on the task at hand to avoid distractions. At the start of each day, I know what will deliver the most value and eliminate what doesn’t make sense.

As for leveraging tools, I use Notion for this. At the end of each day, most of the tasks I complete should be Medium-High priority. If I notice that there are multiple Low priority tasks taking up my time, I reassess their importance.

Since I am a solo Engineer, writing serves as my retrospective, allowing me to reflect on everything I learned during this sprint. Previously, I would do this in my personal notes, but now I write it as an article in case it can help others learn from the lessons I’ve learned. This practice helps me become more introspective and avoid repeating the same mistakes.

Personal sprint board

Lesson #4: Shifting Left the Plumbing

“Shift left” is a term I first heard from my mentor. It essentially means doing things early on or preparing early for what will cost a lot in the future. Imagine if your application was a stock trading platform in a big bank, and a bug arose in production where there are already millions of trades happening. To fix this, it would cost thousands of dollars because you would have to gather all the logs, check the database, inform customers, and maybe even pause trading until the issue is resolved, depending on its severity. If you had proper testing set up, that potential disaster could have been avoided.

Image from: https://lightrun.com/shift-left-testing/ Now, how does that translate to building your own product? There were several plumbing tasks that I put off until later when I was close to launch, but I should’ve done them earlier:

Parameterizing my domains — Switching between different environments was really painful because I manually had to keep changing domain names. Environment Configuration + Logging — I didn’t have a notion of dev, test, prod during my development until I encountered unexpected issues only in the production environment. My logging was all over the place, so I had to manually comment out each log entry depending on which environment I was in. If I had set up different levels of logging (INFO, DEBUG, ERROR), I could’ve simply flipped a switch in production and saved a lot of time debugging. Secure by Design — I was using the prebuilt checkout basket by Stripe to help me get started, but close to launch, I noticed that there was no validation of whether the URL was secure or valid at all. Essentially, people could just come in and copy-paste the URL, and it would still work. I had to scramble to fix it towards the end Conventional over Configuration — I had a different way of loading up my configuration files in my Flask API. Essentially, it would look for a properties.ini file from my local environment and load all the configs from there. I thought it was pretty simple until I had to deploy to an external provider. The convention was to use environment configurations via arguments. For example, it would have been much simpler to have API_KEY set in the shell rather than loading it up from a properties file because software like AWS and Heroku expect you to provide it directly for your application context instead of looking for an external properties file. A final note on plumbing, most of the code you build will be the same thing over and over again. That shopping basket you built now? The next shopping basket will probably be more or less the same. Build a library of snippets that you repeatedly use so that you don’t keep building the same functionality from scratch each time. I have my own library of various things for full-stack development like infrastructure as code, UI components, authentication, and all sorts of snippets that I am looking to share with the public soon.

Lesson #5: Be Polyglot

There is infinite value in being able to build on any platform or language that exists. There is no perfect platform or language; each one delivers its own value proposition. Being able to leverage each one of them will help you scale yourself more. Here are two examples:

Python/Javascript — Currently, Python is well-suited for technologies related to AI/ML due to libraries like Numpy/Pandas that can handle millions of records concurrently and support advanced computations. If you are limited to using Javascript, you would have to build more just to handle the same number of records. I am currently upskilling myself to learn Svelte to speed up front-end development. Google Domains/GoDaddy — I own a couple of domain names in GoDaddy, but I learned that Google Domains offers built-in searchability and reporting, whereas with GoDaddy, you only purchase the domain name at the same price points. Heroku/AWS Amplify — Deploying a backend application on Heroku was pretty straightforward; I was able to go live almost instantly by running a simple CLI command. However, when I started deploying my frontend, it didn’t support different versions of React. Since I knew how to deploy on AWS, I was able to leverage Amplify for my frontend. I learned about these technologies just by doing and being curious. In the long run, having all the necessary tools helps you elevate your game.

If the product you are building never takes off, you will have accumulated knowledge across domains that employers will find invaluable.

Bonus Lesson: Know That It’s Possible It took me 2 weeks from idea to a live product: https://www.insurancepolicyai.net

I wanted to share that it is possible if you set your mind to it. I learned numerous lessons, but once you learn these lessons too, that idea that has been circulating in your head is possible to build without taking months.

(Yes, it only took 2 weeks with 7 straight days towards the end of June! :D See my GitHub for proof: https://github.com/mel3kings)

Thanks for reading all the way to the end. For further updates, follow me on: https://twitter.com/meltatlonghari3