Tl;dr

I spent a month building email addresses validation service and now it is live on https://smartlyse.com. Currently, access to the alpha version is invitation only, but you could leave access request, and I will try to do my best to let you in.

Long version

Once upon a time, I decided to participate in the very special Hackathon. The reason I want to write about it because this hackathon is not the common one where the bunch of the people sit together and build projects that usually get orphaned next day after the event. Hackathon I planned for myself was the one that supposes to kick my laziness out and make a good foundation for the future.

Pretty quickly I formulate the constraints for the hackathon - 24 hours during which I will do my best to finish the product, or at least to push it to the vital point. So far it was tough for me to deliver something workable outside of my day job, to trick my brain and make it more rewarding I call it "24 hours product challenge."

Product idea

Recently it becomes widespread to give away digital content in exchange for an email address, and  I know that people very often use "temporary" email boxes what in the end make content makers suffer. Based on this assumption I decided to build a service that could determine if the email provided by the customer is "temporary."

What did I have before the Challange day

It won't be fair to say I did nothing before challenge day. In reality, I've done quite a lot of preparational work upfront. In the sake of better readability, I'll separate it into the 2 buckets: technical and product work.

Product work

Checking out competitors

From the pure product point of view before starting it is important to understand if the assumption about the problem has any kind of ground. There are different ways, but one of the simplest is just to search if someone else offers such service. Many people could be discouraged by the competition but from my understanding of the world of SaaS competition is usually a good sign. Generally existing of the other providers on the market prove need and market existence.

Researching the target customers groups

This part was a pure guess about the people who potentially need the service I'm willing to provide. I figure out seven groups of customers who potentially need the assistance, for example, digital content makers who give their content in exchange of email address or online services providers who offer a free trial without asking for the credit card number upfront.

Writing necessary wording for the landing page

There is a good practice I found on the internet about making landing pages - approach suggested by Jason Fried, and popularised by Justin Jackson in his marketing course. In short, it is all about the way we present the product - features vs. benefits, Justin brings it even further with the proper practice to write the landing page text before singe drop of HTML.

Technical work

Server side

First of all, I realized possible load on the server and chose appropriate technologies. In the past, I had experience working with Scala and really enjoyed it, so I decided to spawn the project in the Scala ecosystem. I believe that if I need to deliver something really fast, it is better to pick full stack framework and build a monolith rather spend days and hours orchestrating microservices zoo. There are not many full stack frameworks out there in the Scala world, so I decided to give a try to Play framework as most famously known. I will regret this decision many times in the future, but at the moment when I am initializing the project, I don't know anything about future hurdles yet.

Frontend

I had few discussion about frontend stack and what kind of technologies I should use for the front end. I decided to stay with a simple solution - Twitter Bootstrap and Materialise design rendered on the server side, without any kind of fancy frontend framework such a React or Angular.

Database

The database was a straightforward choice for me; I just pick the best thing on the market of the open source relational databases - Postgres, and do not regret it.

Challenge day

In Europe we have these strange days in the middle of the working week where most of the people are not suppose to go to the job and can spend time with their friends and families, we call them "public holidays."  It is fair to explain that this kind of days sometimes can be on the weekend days as well. Anyway, this year May 1 I had a day off my day job because of the public holiday, so I decided to use it wisely and schedule my hackathon/challenge on that day.

The funny thing I decided to do is to stream the process into the Twitter, and I think the tweets from this day will describe the process better than anything else.

It is 00:05 and I begin my 24 hour challenge to build a product.— Andrii Kravets (@AndriiKravets) April 30, 2018

24 hour product challenge
What was done in the first hour:
Launch TODO list
Internal classes structure for project
Started codding implementation— Andrii Kravets (@AndriiKravets) April 30, 2018

Second hour of my 24 hours product challenge in gone and it is time to share what was done.
During this hour I manage to code one of the checking services for the project and now, mowing forward to write code for Ngramms checking— Andrii Kravets (@AndriiKravets) April 30, 2018

03:02
Still struggling to make Ngrams based checks working properly— Andrii Kravets (@AndriiKravets) May 1, 2018

So one more hour pass and time for updates

I spent this hour still working on ngrams =(

Probably I should not spent so much time on making code beautiful, great test coverage and so on and just finish it.

Anyway now i have to wait while code is counting most frequent ngramth.— Andrii Kravets (@AndriiKravets) May 1, 2018

Bigramms kind of ready, waiting for trigrams computation to be done— Andrii Kravets (@AndriiKravets) May 1, 2018

Ok, time to take a break for a few hours— Andrii Kravets (@AndriiKravets) May 1, 2018

12:19
Half of the time devoted for my 24 hour product challenge is gone and only 2 hours was spent for sleeping.

Time to speed the thing up, cut the edges and deliver the product as expected.— Andrii Kravets (@AndriiKravets) May 1, 2018

24 hour product challenge

40% of business logic required for alpha release is done.— Andrii Kravets (@AndriiKravets) May 1, 2018

Tests are failing - sounds like a great time to go for a walk to recharge the brain— Andrii Kravets (@AndriiKravets) May 1, 2018

23 hour of my 24 hour product challenge pass and it is time to make a review

Product is 80% ready.
Main features are done.

TODO for alpha:
- Landing pages for different customers segments
- Fine-tune API

I've done in a 23 hour more than in the last 2 month on my side projects— Andrii Kravets (@AndriiKravets) May 1, 2018

Overall I had around 4 hours of sleep during that particular 24 hours, but despite that fact, I felt my self very motivated and full of energy.

There are some things I like the most and would like to share them:

1.  I'd love to mention is how fast was my development iteration. I wrote the code, design the system and did plenty of different things rapidly and in the end, I got a great outcome from this day.

2. Another one was my ability to switch my brain from focus to diffuse mode by taking 3 long walks. Each time it refreshed me and gave a lot of encouragement to move forward. In general, I really like to have the ability to take a few breaks over the day just to enjoy being outside and walk for a while.

Overall the day was incredible, and I keep thinking that in general, it was because I was the owner of my time and I totally own when, how and what I should build.

After challenge

For the next few weeks after the challenge day, I mostly did nothing for the project even despite the strong feeling that it is somewhere really close to the launch. This kind of apathy is something that makes me sad, so i dug deep enough into myself and tried to find reasons why it happens.

The reason I found was literally just mental and physical exhaustion after the day job, so I was not really able to keep everything running. I found a reasonable solution to finish the project and to make myself happy - take a  vacation and finish the product.

The naming of the product was a super hard as usual because I wanted to have the right name and pick .com domain, recently this combination became rare, so I spent a few evenings brainstorming possible solutions. Final one happens to be invented by my lovely wife. "Smartlyse" - a combination of two words smart and analyse because they represent the nature of the product really well.

Makeation

With this Tweet I start my Makeation.

Let the "Makeation*" begin!

*Makeation - taking a vacation from the main job in order to make a side project =)— Andrii Kravets (@AndriiKravets) May 12, 2018

Taking the vacation, in general, was not enough, so I also decided to change the landscape around me dramatically. In the end, I took 2 weeks of vacation, bought a ticket to south-east Asia and prepare for making.

The first week of the makeation I spent trying to rest after a long flight, fight jet lag and cut all mental connections to my day job. In the end, I think the week spent in this way made me very productive and goal oriented.

I recently surrounded myself with a lot of digital nomads and following their adventures made me think that it is a dream path, you are laying on the beach and delivering some cool features. Unfortunately, my dream was ruined. It was destroyed by the scorching weather that forces you to spend time only in place with an air conditioning and lack of proper and quiet places to do stuff.

Release and the current state of the product

On the June 1, I released first alpha version that already supports the REST API calls and could make the bunch of different checks of email address to prove that it is "junk" or not.

The product is released in the invite-only alpha version, but it is possible to leave the alpha version access request on the product site so I could review it and grant access to the API.

Future plans for the project

Right now I keep working in many fields at the same time, most important one is probably related to marketing and overall system quality improvements. I suspect that there are still many edge cases exist where the service could give not accurate results, so perhaps next month will be spent trying to fine tune it and find more customers.

Most important learnings

1. Building product and building project is not the same

At the beginning of the story, I mention that I pick the Play framework for the product and regret it. Despite Play framework is excellent I had a limited amount of experience with it, so the whole process of development became a fight with it instead of using it as leverage for faster growth. I think one of my tweets summarize it in the best way:

My dev routine is insane:
20% <- features delivering
80% <- fighting with framework.

Time to say goodbye, and migrate over so something more friendly...

Will try to track approximate amount of time needed for the migration— Andrii Kravets (@AndriiKravets) May 25, 2018

This is why I think it is important to mention that making product mean as fast as possible cross the finish line and iterate on the assumptions about the usefulness of it. To satisfy this statement, it is much more efficient to use well known boring technologies instead of cool and hip ones.

From the other side, side-projects have an entirely different nature and end goal because they intended mostly to entertain and become a sandbox for new skill training. This makes them a great candidate for the hip and fancy technologies.

For myself, I decided to operate in a way when I do not use more than one new technology in the product to minimize the risk of not delivery but in the same time to make it more entertaining and fun to develop.

In the end, I migrate almost everything I wrote using Play framework to Spring boot, and now I have a Spring boot project that consists quite a lot of Scala code. Overall it took me around 10 hours to migrate the code from Play framework to Spring boot.

2. Do not tell anyone about the project until it is almost done

I made a big mistake with my previous product when I tell everyone what am I doing and this tricked my brain. I unconsciously start thinking that project is done and this is really demotivating to keep pushing it forward.

During development of Smartlyse, I knew it and did not share anything else except the fact that I am working on something. Most people probably was a little bit confused because it is widespread in startup world tell everyone what is going on and what are you doing but when I explain how my brain works people accept it just fine. From the other side, I found useful to chat with people about exact idea somewhere after 90% of the product is done because in this case, it works for me as supporters close to the finish line for a marathon runner, encourage and motivate to make the last step, and close previous tasks.

3. It is hard to find people who can help

I found useful to focus more on the core skill set and outsource the weaknesses. For example, I tried to find someone who could help me with HTML and CSS, but unfortunately, most of my friends are pretty highly skilled so they will not enjoy doing dummy things with plain HTML and simple CSS libs.

I ask for advice from the friend of mine about finding the right people, and his answer did not make me happy, it is a long, hard and expensive process.

4. Outsource as much work as possible

My time is not scalable, there are so many things I need to finish to make the product shine, but I have only around 4 hours of free time every day to work on it, so it becomes crucial to outsource some of the tasks to someone.

Right now I understand how much time I waste by doing the things wrongly and overspend incredible amount of time, just making simple calculations shows me that it was reasonable to outsource all frontend to freelancer.

By the way if you are cool frontend dev who is looking for a side gig just ping me on Twitter.