Unfinished side projects are the bane of a hacker’s life. How many incomplete apps are languishing in forgotten folders, 80% finished but destined never to see the light of day?
It’s the Dev equivalent of writer’s block. We love working on the interesting and the challenging parts, but it’s that final 20% that kills us. The mundane and the dull — the bits at the end that make all the difference between code that runs locally and a published app that anyone can download or use. It’s the difference between a side project and a product.
But writer’s block is not real. It’s a state of mind. The writer can choose to move past it by showing up every day. And just like the writer, the developer can choose to plow through that final 20% that leads to release day. You just have to know how close you are to the finish line.
We’re inundated with release stories that make it all look easy, and we wonder what we’re doing wrong. Version 1 of Stripe took two weeks to build. Young devs fresh out of college post to Hacker News about apps they built over the weekend. What are they doing that we’re not?
They’re releasing. Shipping. Publishing.
The idea for my latest app came to me on Saturday, January 23rd. It went live on Azure twelve days later after forty-four hours of development. Two days after that I posted it to Hacker News.
This is a breakdown of how I progressed the app each day — moving one step closer to release every single day. I wasn’t burning the midnight oil. A few hours a day in between other projects. It was all very calm.
Days 1 and 2: The Idea Phase [2 hours]
My idea was to build Imgur for text. A simple and quick way for anyone to post and share rich text online — all without needing to set up a website or open an account. Rapid-fire and barrier-free publishing.
I spec’d out a list of features required for an MVP that I called Stage 1, then added a host of potential additional features that might lead to a paid plan at Stage 2 and a corporate plan at Stage 3. I don’t write code for free and consider it important that everything I build has at least the potential for turning into revenue down the road.
On Day 2, I discovered Pastebins and realised my new idea wasn’t so new after all. But I decided (rightly or wrongly) that offering rich text editing and a distraction-free UI was unique enough to proceed to the development stage.
Day 3: Decisions [2 hours]
Monday afternoon I fleshed out the technology I’d be using to build the app. Choosing to use the newest and shiniest frameworks is a common mistake when devs start working on side projects. What should take one day takes five; what should be problem-free becomes a can of worms as you spend more time learning and battling the technology than you do building the app.
I went with boring and simple and decided to use what I was already familiar with. .Net Core and MVC for the bones of the app with a DevExpress component I’d used before for the HTML editor, all hosted on Azure and stored in a SQL server database.
Boring and simple.
Next, I needed a catchy name and a short URL. The list below gives some indication of the direction my mind was moving before I landed on QuikPub.co. I needed a domain name that was available and global, and an app name that didn’t already have a strong Google presence (Technically .co domains are not global, but in practice they are).
I discounted QwikPub after finding an urban dictionary reference that suggested the word Qwik had sexual connotations in some circles, and decided against anything with Writer in the name as that was suggestive of a creative writing app rather than a publishing app. Decision made, I parked buying the domain for a couple of days in case I changed my mind.
Day 4: Building the UI [5 hours]
The core feature of the app was the rich text editor, so it had to be robust and user friendly. I decided to use a DevExpress component which was based on the Quill editor. My reasoning here was that I already had a license for their component suite, and my previous experience with DevExpress showed that support issues and questions were answered quickly — something that would come in handy on Day 10.
The bulk of Day 4 was spent getting the HTML editor configured and working correctly, ensuring it was displaying the buttons I wanted it to and that everything was being posted to the backend without issue.
Day 5: The Database & the Backend [4 hours]
Nothing too difficult or complex here. I wrote a script to create the required tables in SQL Server and hooked it all up to the app using the latest version of Entity Framework in .Net Core. I was working with a local instance of SQL Server at this time as I hadn’t yet set anything up in Azure — that would all come later.
Before signing off for the day I bought the QuikPub.co domain name. One year only, as who knows if the app will be around in twelve months.
Day 6: Polishing the Backend [8 hours]
This was my only full working day on the project and it was spent putting all the pieces together and making sure they flowed correctly.
The day involved fleshing out the service and repository layers of the app, putting everything in place to allow for creating and editing QuikPubs. All very mundane and nothing any dev hasn’t done a hundred times before.
I built the View page — a lightweight page that did little more than render the rich text entered by the user. It was accessible via a short URL, which was a bit tricky to get working in .Net MVC, as the usual routing recognises the short URL as an unknown controller class. I got around this by implementing a “catchall” controller action.
The Logo
By now I knew I was a few working days away from going live, so I needed to get moving on the logo design. In the past I’ve used 99designs, spending a few hundred Euro a time, but this was a rough and ready MVP that might or might not have a future so I elected to go quick and cheap with a design team over on fiverr.com.
I gave them a few examples of logos I liked along with a preferred colour scheme, paid $75 and then put it out of my mind. They had a three-day turnaround which would put the logo delivery at around the time I’d be polishing the UI. Perfect.
80% Complete — The Danger Zone
This is what I call the 80% stage, when most side projects come to a halt. Everything works — kind of — but there are outstanding issues that need fixing and a lot of little things that need to be done before you can release your app.
The next few days illustrate what’s required to go from side project to product, from functional code to releasing an app. Without the next few days, all you’ve got is code, code that only you have seen and run.
If your side project was intended to be anything more than a code learning exercise, it doesn’t count until you plow through the next few days and release it.
Day 7: Page Flow [3 hours]
This was a follow on from the previous day, fixing some issues with page flow caused by the catchall routing. Once I had that fixed and working I added in a delete option so the user could delete as well as edit an existing QuikPub.
The DevExpress component suite I was using had some attractive pop-up messages built-in, so I added these to the flow. By end of day, everything was working and looked pretty good.
Day 8: Unique ID Generation [6 hours]
Each user post generates and stores two unique string IDs that allow viewing or editing a post. Up to now, I’d been using a few made-up IDs that I’d hardcoded. The time had come to automate this.
I went backwards and forwards on how to generate these IDs over the course of the day before settling on a 10 character string for viewing the post and a 32 character string (not a guide) for editing.
Decision made, I had to update the database structure and accompanying data objects, as well as make changes to the catchall controller method to route everything correctly.
Day 8 was a Saturday but it was raining out and we were still avoiding restaurants due to rising case numbers so I didn’t mind working. Towards the end of the day, I set up the project in Azure DevOps and made my first code check-in. Azure Devops integration with Visual Studio is flawless, so this only took ten minutes.
Day 9: Website Theme [4 hours]
The logo arrived that morning. It was ok, but not great. I can live with it for now but if QuikPub proves to have legs I’ll have to get something more professionally designed.
I picked up a bootstrap theme called Square the previous day, as one of the landing pages looked perfect for QuikPub’s home page. Up to then, I’d been working with a bare-bones .Net page, with the HTML editor as the sole item on the page. Now I had to flesh that out with explanatory text so that users landing on the website knew what the app was and what they could do with it.
I spent most of Day 9 getting the theme in place with its default lorem ipsum text above and below the HTML editor, and changing the css to match the colour scheme of the logo. The Publish image used at the top of the page came from DepositPhotos and cost about a euro.
Day 10: Bug Fixing and Content Writing [5 hours]
I spent a couple of hours writing the content for the Home page that morning. Getting this right is important. If a user has to ask what your app does, then your message is failing. Clear and simple English.
I added some QuikPub examples at the bottom of the page containing blog posts I’d written and published over the past year — good enough to show what was possible with a QuickPub.
Most of the day was spent troubleshooting a jQuery issue caused by a conflict between the DevExpress components and the Square UI theme I was using for the website. Basically, none of the DevExpress components were initialising correctly, with errors popping up in the console on each page load.
I’m not a UI developer and my javascript isn’t particularly strong, so I opened a ticket with DevExpress support and sent them a sample project illustrating the problem. They came back to me within an hour with code samples showing how to initialise their components without using jQuery.
It worked. No more time wasted.
This is a perfect example of where paid-for components outperform free open source components. Try getting a one-hour turnaround for support on something you’re not paying for!
Day 11: Release Day [5 hours]
I was ready to go live. Everything was working, the page content was all there, colour schemes and images were all chosen and in place. But there were a few little items that needed to be finished off, as there always are with any project just before it goes live.
I needed a small Admin area so that I could keep an eye on things in case they got out of hand. But the app had no user accounts, so how and where would I build that admin page?
I went with obscurity over security. A quick and dirty Admin page accessible via a URL that could not be guessed, coupled with a requirement for a random cookie to be pre-set in the browser. It’s not foolproof and anyone with access to the C# code in the backend could get around it by identifying the cookie, but it was good enough considering the app was not storing any private or sensitive user data or information. It took a couple of hours to put in place.
Around midday on Wednesday, 3rd of February, I created the new App Service in Azure and a new Azure SQL database. I spent about an hour trying to get Let’s Encrypt working for the app service SSL cert, all to no avail. There are a host of long-form articles written about how to do this, as well as plugins to help you along, none of which worked.
Microsoft doesn’t support Let’s Encrypt out-of-the-box, so every implementation is a workaround and it looks like they break frequently. In the end, I’d had enough. I wanted to launch that day, not waste any more time on Let’s Encrypt, so opted to pay for the SSL cert via Azure. It took 10 minutes and about €50 to get it all working.
The final step was to set up the support email address on the QuikPub.co domain and point it to my Fastmail account. This involved a few DNS changes and took another ten minutes. I have multiple domains feeding wildcard email addresses into a single Fastmail account — well worth the money.
I was ready to deploy.
A final code check-in with a suitably celebratory comment and I published direct from Visual Studio to my new app service. As a first deployment, it took about three minutes, and the home page opened without issue.
I had a couple of problems with database access, outlined here in the first-ever production QuikPub: https://quikpub.co/3K5MIPZGWP
There was one last loose end to tie up — screenshots on the home page that showed examples of short URLs, all pointing to localhost. I had to create some test posts on production and re-take those images, then re-deploy. The same with the sample QuikPub links on the home page.
And that was it. I spent half an hour testing the new app on production, then called it a day.
There was no post to Hacker News, no Twitter or blog entry, no email to my mailing list. Experience has taught me that it’s useful to let things sit for a day or two before telling the world. Something always comes up — a bug or a spelling mistake that needs fixing or a change you want to make.
Day 12: Show Hacker News
It was on Friday afternoon, February 5th, after forty-four hours of development that I posted to Hacker News. For anyone unfamiliar with Hacker News, it’s THE social news site for developers. They have a Show section that allows developers or start-ups who’ve built something new to post it and talk about it on the site, where it then moves up or down the rankings in a Reddit-like fashion.
Dropbox, Stripe, and many other mega start-ups began their public life on Hacker News. It’s a big deal and can lead to a lot of early exposure, feedback, and page loads.
Here’s the post: https://news.ycombinator.com/item?id=26035551
QuikPub spent about a day near the top of the Show page and a similar time near the bottom of the main page. Not a spectacular result but good enough to lead to 5,000 page loads, over 600 new QuikPubs created, and a host of comments on the app itself. The comments were particularly useful in tracking down and fixing HTML sanitization and css issues, while the 600 new QuikPubs helped me track down some backend bugs.
Feedback was light when it came to the functionality of the app itself, with not a lot of enthusiasm being shown. Ideally, I would have liked to have seen more comments on the app and how it might be used. But that in itself is feedback, which I’ll need to ponder on.
Conclusion
There’s nothing particularly difficult about anything I did over the course of those forty-four hours. Any developer with a little experience could have done the same. A strong UI developer could probably have shaved 10–15 hours off that time frame.
What makes it different from so many side projects is that it got as far as release day. By end of Day 6, most of the heavy code had been written and most of the problems had been solved. But it was those final few messy days of bug fixing, content writing, colour picking and production setup that made all the difference.
They are what made QuikPub a releasable app.