.Net Core, QuikPub, Solo Developer

From Idea to MVP to Hacker News in 44 Hours

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).

Potential Names

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.

HTML Editor

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 light weight 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 hard coded. 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 guid) 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.

Short URLs

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 professional designed.

Logo

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.

Home page

Most of the day was spent trouble shooting 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 out perform 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 fool proof 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.


To hear more from me, you can follow me on Twitter or on LinkedIn.

Gryphon SQL, Solo Developer

Excel to SQL — Bridging the Gap Between Business Analysts and Developers

The Problem

Business analysts and developers work with data in different ways. By and large, analysts work with Excel spreadsheets output from company applications, from Power BI reports, or from CSV extracts provided by developers. The developers themselves tend to be more comfortable accessing raw data via SQL queries.

The difficulty with this divergence is that it’s often the business analysts who decide that selected data records need to be updated, and it’s then the job of the developer to perform that update.

The problem then becomes how to update a SQL database from an Excel file that was manually created or edited by an analyst. The developer has a few options:

  • She can train the analysts to produce a file formatted in just the right way and write a common script to parse that file (not practical when different data is being updated in different ways).
  • She can take a crash advanced course in Excel to try and work out how to extract SQL from rows of data (possible for simple INSERTS, but not for complex scripts).
  • She can write one-off custom code to produce the SQL script required. Different code for each update.

For anything more complex than a simple INSERT script that mirrors the Excel file, the developer is likely to take the more time consuming and costly option of writing custom code.

I’ve encountered this problem repeatedly in many different companies over the past 10 years. Small eCommerce operations, large multi-national financial services companies, and the SMEs in between. Even large government agencies are not exempt.

Existing Solutions

Google “Excel to SQL” and you’ll find a host of free and commercial solutions to this problem. But none of them are robust solutions capable of solving genuine business problems and use cases. They work if you’re playing with student or hobby projects, when all you want to do is take a CSV file and create one INSERT statement per row.

But that kind of simplicity rarely exists outside the classroom. Here’s an example of a more common use case, where business analysts worked with user data of an Enterprise App that was undergoing a major improvement. An update script was required for each user that met certain criteria.

  • An INSERT record to a separate table for dormant users, followed by an UPDATE to a core user table.
  • An UPDATE to connect each user with a newly created companies table, if the user email exists and if the company name exists in the database’s new Company table.
  • A bulk update of roles assigned to a user — again, only if that user’s email address exists. The bulk update might include a DELETE followed by a series of INSERTS for the user.

Individually, there’s nothing overly complex here. The complexity lies in generating a single SQL script based on the Excel file that contains the changes required. The script generator would need to read each row, check the contents of specific columns for certain values, and generate one of many scripts based on what it finds, inserting values from other columns into the script automatically.

This is far beyond the scope of any “Excel to SQL” SaaS app you’re likely to find from a Google search. Which leaves the developer with custom code, every time.

I first encountered this problem years ago and went looking online for a solution. It seemed to me that if I was having this problem, so too were other developers. I was expecting to find an off-the-shelf app or library that allowed me to open an Excel file, tweak a few parameters, enter some SQL and click a button to generate my script.

I was mistaken. No app. No .NET library. Not even an over priced SaaS product that would help me.

My Solution — Gryphon SQL

This is the problem that I’m trying to fix with Gryphon SQL [1]. It functions as a text replacement tool that combines Excel file parsing, conditional checks on row and column data, and smart SQL-aware string replacement. At its core is the ability of developers to generate a custom SQL script based on their own SQL template of one or many queries.

It can handle the above User data example with relative ease, generating a series of scripts to UPDATE dormant records, DELETE and then UPDATE roles for a user, and UPDATE user records to apply company IDs based on the supplied string values of “Email Address” and “Company Name”.

It’s early days for Gryphon SQL. With Version 1 I was very much scratching my own itch, building a tool that met my own unique requirements and use cases. Version 2 will be a more fully featured app, ready for prime time use by developers everywhere.

Oh, and a website. That would be good too. 🙂

[1] More about Gryphon SQL.


To hear more from me, you can follow me on Twitter or on LinkedIn.

Solo Developer

From Side-Project to Alpha Release — What Developers Can Learn from Writers

“Ideas are easy, implementation is hard.” Does this sound familiar?

If you read the same blogs as I do, hang out on the same websites, listen to the same podcasts, you’ll have heard this gem a thousand times. But rarely are we offered advice on what to do about it. How do you get from idea to product? How do you get through that implementation phase and see your app released to market?

So many side-project developers hit the coding equivalent of writer’s block. We have the idea, we know how to write code, but we can’t seem to progress our app. Disparate bits of code, and Word documents filled with feature lists languish in folders called ‘Ideas’ or ‘Projects’. They sit there as a constant reminder of our failure to see things through, perpetually signalling to us that we’re not one of those people; that we’re not Mark Zuckerberg, Jack Dorsey, or Stewart Butterfield.

The American writer Anne Lamott wrote a great book called Bird by Bird. Subtitled “Some Instructions on Writing and Life,” it offers up pearls of wisdom that are as well suited to the solo developer building an app as they are to a writer beginning work on a novel. Her two most helpful pieces of advice are: Short Assignments and Shitty First Drafts.

Short Assignments

Just like a writer is not writing their whole novel in one sitting, you’re not building your entire app today. You need to focus on one small thing, not the entire app with all its dependencies, complexities, and unknowns.

As you start out, there are a host of things you don’t know, problems that have to be solved that you haven’t even begun investigating. You’ll need to work with technologies you’re unfamiliar with, build layers on top of layers into your code, interact with third party services that you know are going to be buggy or difficult to understand. You’ll have a feature list as long as your arm, a vision in your head of a polished UI, and a fear of releasing something sub-standard that gets you mocked on Hacker News.

Anne Lamott’s advice to writers in a similar situation is to focus on something small when they sit down in front of their keyboard. A paragraph where one character meets another, a setting introducing a small town. No more. Forget the novel, the grand themes, the huge scope of what you want to achieve. Today, the writer’s job is to write that one paragraph.

For the developer, when you sit in front of your screen your job too is to build one thing, and to keep that one thing as small and as simple as possible. Today, a database schema with a few interacting tables. Tomorrow, an API with a single endpoint that returns data from that database. The next day, a page in your app that calls your API and displays that data.

One small step at a time. No need to investigate authentication at this stage. Park that for later. Ditto for building your database on Azure or AWS. Keep it local and keep it simple. This way you achieve something every day. You progress your app each time you sit down to work.

It’s the slow accumulation of all these short assignments that grows your side project from idea to fully implemented product. One small step at a time.

Shitty First Drafts

A published and acclaimed author presents an almost picture-postcard image to the world. That image is often of a great writer who writes poetic or flowing prose, captivating characters, and engrossing novels. But it rarely starts out like this. Not for Hemingway, not for John Grisham and not for JK Rowling. First there was the shitty first draft. Then the second draft that was better but not quite there yet, and so on until a polished novel appears on the shelves of the local bookstore.

If a writer doesn’t finish a first draft, they’ll never finish a second or a final draft. The same goes for every developer working on a side project in the evenings and weekends. Allow yourself the luxury of creating an imperfect and clunky alpha version of your app. Don’t be the perfectionist who writes some great modules of code but never releases a version 1.

You’re working in isolation with no eyes on you. It’s more important that you get that early version finished and released than it is that every line of code is optimised and every feature immaculately constructed.

Your early users will be few and far between. As you grow your app you’ll have time to edit and improve: to polish the code, refine the UI, streamline the user experience and add richer features. If you try to make it perfect in every way before you release that first version, or if you stop work because you don’t think you have what it takes to build a great product, your app will never see the light of day.

Facebook, Twitter and Slack were not built overnight. However polished they looked when they were in their prime, there was a shitty first draft. If your early versions are messy, that’s ok. You can clean up the mess later. And who knows, inside the mess you may discover the soul of your app, that special something that makes it truly unique and yours.


To hear more from me, you can follow me on Twitter or on LinkedIn.

Solo Developer

6 Stage Development Plan for a Solo Developer Building a New App

A solo developer building a fully featured commercial application faces a number of challenges not faced by startups and dev teams, the largest of which is he’s on his own: one decision maker, one perspective, one opinion, one set of skills and experience.

There’s no one to shout out when a bad decision is made, there’s no voice of dissent in the room, no one suggesting alternative solutions. The solitary developer has only his own experience and knowledge to rely upon when building something new and pushing it out to market.

What’s generally absent from the solo developer’s toolkit, and what would help mitigate the effects of this isolation is a detailed development plan, a full roadmap taking in the first year of the app’s development.

My six stage development plan for building a new app is designed for solo developers just like me, looking to take a new product from initial idea all the way to a commercial application selling to users and companies around the world.

Saying “Ship it” is easy. Actually shipping that polished app is hard. Most solo developers fall down because of a failure to plan. They’re devs, so they want to code, not write documentation or outlines. But it’s that strict development plan that makes the difference between success and failure for so many side-project devs.

Why six stages? Why not a long list of features and to-do items?

You need milestones. You need to feel that sense of achievement as you complete Stage 2 and move on to Stage 3. You need production release builds with sets of features planned out in advance. You need to see those release dates coming and celebrate as they happen.

You need to be able to drag a feature from Stage 3 and drop it into Stage 4 or even Stage 6 after early users express complete disinterest. You need a structured place to add new features and ideas that will come to you as you work, instead of rushing headlong into building them now.

Before I dig into the six stages, a word of caution. This plan is all about the technical process of building your app; it does not address the product / market fit question. Are you building something people want? Something that people will pay for? Are you solving a genuine problem or addressing a real pain point? That’s the subject of another post (or book), but for now I’ll point you to a truly excellent book written by Rob Fitzpatrick called The Mom Test. I wish I’d had access to this book ten years ago.

Once you have your idea firmly fixed in your mind, you need to identify the niche market you’ll be building your early versions for. You should select the smallest niche possible so you can more easily dominate that sector. You’re a one man band, not Microsoft. You don’t have the resources or the time to build a generic app right now, and if you did you have no way to reach all those potential users.

Start small and stay focused on your niche.

Stage 1. Decisions

Before you write a single line of code, before you pull together any wire-frames or sketches, you need to make some decisions on the tech stack you’ll be using for your new app. To do this, look at two things: the requirements of the app and your own skill set.

If you’re building a desktop app, will it need to be cross platform? For a web app, will it be used primarily on mobile devices, on lap tops and desktops, or on both? Once you’ve worked out what the use cases will be, you can decide what kinds of tech you should be looking at.

The next step is to look at your own areas of expertise and see if these can be used to build everything you need. If you’re a .Net guy like me, is .Net Core strong enough to build out your backend? If your database experience is all Oracle, is that a viable database to use for a SaaS app? If not, you’ll have to step outside your comfort zone and choose something else.

What about the UI? If you’re a full stack developer with strong experience with Angular, then you’re in luck. If your UI experience is all jQuery version 1, you need to take a hard look at whether that particular library is strong enough for the app you’re looking to build. If you’re a backend developer with little UI experience, you need to look for a UI framework that’s quick and intuitive to learn.

Let’s assume that your experience gives you 80% of the skills you need out of the box. That leaves 20% of the tech you’ll be using that you’re unfamiliar with. You need to start learning this right now. Watch some videos on Pluralsight, Coursera, or YouTube. Buy a book or two on Amazon and plow through it quickly.

Look into third party tools that can save you time. You don’t have to decide on these right now, but you should be aware of them so that when you do reach the stage that they might be useful you don’t find yourself spending a month building your own solution when an off-the-shelf package would do all the work for you at a small cost. Do this before you move to Stage 2, before you write any code for your app.

What about the hosting? Do you need to decide on this right away or can it wait? My experience here tells me to wait it out. Your early pre-release versions will all be running locally. You can decide on Azure, AWS, DigitalOcean, etc. further down the road as you get closer to that first public release.

Stage 2. Localhost

Trim your Stage 2 feature list to the bone. In Stage 2 you don’t want a list of features your early users must have, you want a core set of features without which there is no app. Why? Because you don’t truthfully know what that must-have feature list is yet — you’ll learn that over time as your app starts interacting with users.

So what does a basic working instance consist of? It should allow you to open the app, edit or make changes, and save those changes to the database at the backend.

The goal of Stage 2 is to pull the disparate parts of your application together and make sure they work and flow in sync, that all the bits are in place. Your UI framework and code is all building, it’s communicating with your backend correctly, which in turn is reading and writing to your database.

That’s it.

It doesn’t need to be pretty. It doesn’t need to have a user log in mechanism — at this stage you are the sole user. It doesn’t need to be communicating with any services hosted on Azure or pulling in any external data sources.

Make it run locally, and then start using it yourself as much as possible. Let the dogfooding begin.

Stage 3. Show Hacker News

This is when you show Hacker News. And this is when you ask users to pay you money.

Your first beta release should contain the basic functionality that allows a user to do something valuable and important to them. It’s an MVP where the primary emphasis is on Viable. When you first came up with the idea for your app, you had a starting point, a basic set of functionality that lay at the heart of your offering. That functionality needs to be there now, and it needs to work well and look slick and professional.

At this point you need to investigate and decide on where you’ll be hosting. You also need to allow for user authentication and identity management — preferably using a third party resource that you may have to pay for. I’d recommend taking a look at AuthO.

You should be focusing on what makes your product unique, what separates it out from the competition. You should not be reinventing the wheel, building out login and authentication modules, or rolling your own payment methods. Investigate and decide on third party tools to do these mundane but super important tasks for you. Keep your focus on the unique features of your app, not on the things it shares with all other apps.

Release your beta version and then tell people about it. Your target user at Stage 3 should be the visionaries, pre-early adopters who love trying out new things. Hacker News is where you’ll find them.

Stage 4. Tell the world

Your app is ready for prime time. Now is the time to tell the world, or at least the world where your niche users live and breathe. It has a rich, if incomplete set of features, and it meets most of the needs of the niche market you’ve chosen to target. It should contain many of those enticing features you dreamed up over the weeks or months prior to writing code.

This is the product that a dev team at a large company can often spend months or even years building, and that you’ve now pushed out rapidly. How do you achieve this?

Way back in Stage 1 you made decisions about your tech stack. You decided on languages and frameworks. You should also have decided on whether you were going to roll your own UI components or go with commercial suites of components. Most developers love building new things. Their default answer is always to build their own.

As with authentication and payment modules, this is often a mistake. Sure, it gives you total control over how your components look and feel and behave, but it adds hugely to the time it takes to build your app. Remember, you’re a one man shop on a budget, you don’t have the luxury of spending weeks on every component. You need to be building faster and with greater confidence.

Professional third party component suites will allow you to do that, and will add a consistency that is often missing from solo developer apps. I’d recommend taking at look at DevExtreme for a frontend example of what third party tools can provide off-the-shelf. Don’t shy away from backend components either. Remember, you should be spending your time on what makes your product unique, not reinventing the wheel.

Now go tell the world about your fantastic new app.

Stage 5. Integration

Now is the time to release that Pro or Enterprise edition. If you’re building a B2B app, add in a single sign on option coupled with premium support, all accessible from a new pricing tier targeting larger companies.

If you followed the earlier advice in Stage 3 and used a third party to handle your authentication and identity management, this should be a simple box ticking exercise instead of a major piece of development.

Stage 5 is also where you should look at integrating with other apps and services. Grow your users and audience through add ins and plugins, make it as easy as possible for a new user to fit your app into their existing workflow. Mailchimp is a prime example of how a small company can grow through integrating with other apps.

Stage 6: Expansion

You now have a polished, professional app that meets the needs of small and large users in your target niche. Time to expand and take over the world.

Just as Facebook began at Harvard, dominating a small segment of users before expanding outwards to the wider world, you too should use the beachhead you established building your core app for a small niche and expand outwards.

All those generic features that you left out because they were not specific or targeted enough for your initial users need to be re-opened and looked at with a wider user base in mind.

At this stage you’re no longer a solo developer. Expansion has enabled you to start hiring more devs. You have UX people, dedicated UI designers who bemoan the fact that you chose that third party component suite way back when, and experienced backend guys who constantly critique your early architecture.

Such is life. Welcome to success.


To hear more from me, you can follow me on Twitter or on LinkedIn.

Solo Developer

5 Reasons Your Side Project Never Became a Product

Do you have side projects sitting idle in folders or git repositories, untouched for months or years? How many are 80% complete? Functional and occasionally used by you but not in a fit state to sell or to give away? How many seemed like great ideas at the time?

The sorry state of the side project is the bane of every hacker’s life. We have an idea. We get stuck in after work or at the weekend, all eager and filled with passion. Weeks or even months pass, progress is made and then we stop or we move on.

Sound familiar?

I’ve worked on a dozen side projects that I’ve polished and released. Some have been commercial desktop products, some free online apps, but all reached a state of completeness that allowed me to release them to real users.

Every time, I’ve had to fight with myself to cross the finish line, to get the project into a state where it’s no longer a project but a product. Crunch time usually hits at the 80% mark when it’s usable by me with a little manual configuration. The UI might be a bit embarrassing, important things might be missing, it may be a long way from being release ready.

It’s at this point that my inner demons (and yours) do their damnedest to de-rail the project and prevent it from ever becoming a product.

Here are five reasons your side project stayed a project and never became a product.

1. The boring bits at the end

The early stages of a side project are fun. You and only you get to choose the tech stack — no more libraries that are six years old, no more antiquated IDEs and database clients. It’s new and fresh all the way.

But as the project grows and gets closer and closer to becoming an actual product, the fun gives way to the mundane. It all starts to feel like the day job.

Is the wording right on the menus and buttons? Is everything enabled or disabled when it should be? Have you built the installer, code signed the EXE files? How do you even get hold of a code signing certificate?

It’s a list that never seems to end, filled with annoying little jobs that take all the fun out of building your own app. But they have to be done, otherwise your project stays a project, gathering dust and reminding you every day of your failure.

How do you fix this?

You fix it one task at a time. But first you need to define those tasks, to build a list. Everything goes on the list: the bugs, the cosmetic changes, the missing features, the installer, the website, the user forum, even the code signing certificate.

I know what you’re thinking: “I don’t need Jira for my little side project.” You’re right, you don’t need it for your side project. But you do need it — or something similar — for your product.

As I was building the first version of Atomic Scribbler back in 2017 it was at the 80% stage that I introduced Jira. Atomic worked — for me. But it was nowhere near ready for the wider world.

At 7 AM one weekday morning, sitting in Starbucks on the Quays in Dublin, I built my first Atomic Scribbler Jira list. Everything was on that list — over 100 tasks, bugs and user stories. Some would prove to be a ten-minute job, others would take me days to complete. I listed them all and then I set up my first sprint: seven days, twenty tasks.

That afternoon I was working in another coffee shop and dragged two tasks to the Done list. Each day I repeated the process. One or two tasks in the morning, drag and drop, one or two in the afternoon, rinse and repeat. At the end of that week all 20 tasks were completed and I set up the following week’s sprint.

When you feel the momentum, when you watch as tasks get knocked down each day, the end becomes real. You start to see release day just around the corner. A product, not a project.

2. You lost your focus and drive

We’ve all been there. When passion is not enough, when Netflix or Facebook or shiny new things pull at us, tearing us away from our project. Procrastination can make us lose days, weeks, even months. For many of us it’s the end — we never find our way back to our project and our product dies before it’s even born.

How do you fix this?

There’s an entire industry out there selling answers to this question. Self-help guides whose sole purpose is to help us kill procrastination, motivational speakers who fly into stadiums by helicopter to rescue us from ourselves, not-quite-academic books that talk about Grit and Mindset and Deep Work. All answering the same question in different ways: how we can work better.

I find the most useful approach is to work my side project the way I work the day job. Give myself a boss and do what he tells me to do, just like at work.

What do you do when your boss assigns you a list of small, uninteresting tasks? You grumble, you tap the keyboard aggressively, and then you start work. You keep working, day after day until the list is complete. What do you do when he asks you to write 1,000 words describing some new functionality? You may hate writing, it might not be your thing, but you sit down at 10 AM and you get stuck in regardless.

It’s not the money that makes you do the work, it’s the instruction from a guy you see as being entitled to instruct you.

That final 20% — those tasks that are stopping your project from becoming a product — these are just the sort of tasks you dislike doing in the day job but do nonetheless.

Treat your side project like a job — a couple of hours OT each day. Be the boss. Write up those Jiras and assign them to yourself. Start a weekly sprint and hold yourself as accountable as your boss at work holds you. It won’t be long before that product starts to take shape.

3. It has to be perfect

How often in the day job are you asked to build something quickly, to cut corners, to keep it simple. “It doesn’t have to be perfect, it just has to work. There’s a demo on Tuesday.

Heard this before?

A side project is different. No one can tell us to rush new features, to leave stuff out, to park the unit tests and come back to them later. We’re determined to do everything just right. No shortcuts.

The trouble with seeking perfection is you never get there. Like the writer who keeps revising each paragraph and never types “The End”, you keep finding improvements that just have to be made.

If your app gets a mention in the New York Times you need to be able to scale quickly — better put that in place now, just in case. And what about those French users? They might not be there for version 1, but they’ll be along soon enough — better implement that multi-language support right at the beginning, it’ll save time later. Windows 12 is due out next year — I’ll install the early release candidate and ensure my app is compatible, nip any issues in the bud while the code is fresh in my mind.

This reads like a joke, but it’s not. This kind of perfectionism kills your project before it has a chance to become a product.

How do you fix this?

You need to trim features, not add them. Your version 1 should be the product that is good enough for a tiny proportion of your potential users, not for all of them.

Draw up a list of features and scenarios that you think you have to handle in version 1. Park Jira for now, do this on paper. Write it all down — export options, backups, multi-user support, tags (tags always turn up on these lists), printing, Google and Facebook login, whatever.

Then take out the red pen and go through the list. The question you should ask for each item on that list is: “If I leave this out, can a user still use my product?

That’s it. Not “Will it be perfect?” If one user can use your product without that feature, cross it out. Park it until version 2.

This approach has an advantage beyond helping you get version 1 out the door. Half the items you crossed out will never be mentioned by your early users. It won’t be that they can live without them for now, it will be that they have no interest in them at all.

My red pen list for Atomic Scribbler was huge. I’m on version 6 now and I still haven’t implemented some of the items on that early list — not even the tags. Why? Because a year and a half later with many thousands of users, no one has asked for them.

An imperfect product is still a product, but a project is always just a project.

4. You got bogged down and didn’t know where to go

Like a writer at 30,000 words whose plot has fallen off a cliff, you coded yourself into a wall. Everything was going well, the project was coming together, then you found yourself stuck with no idea where to go next.

You lost your vision for what the project was, or you never had a vision to begin with. You never saw the product.

How can you possibly fix this?

It’s easy to mistake this inability to move forwards for procrastination, but it’s not, it’s worse. Something is wrong with your project. You don’t know where to go next because you haven’t defined your product-to-be or your target user. You’re building something for a generic user when you should be building a product for the smallest niche possible.

With Atomic Scribbler that niche was creative writers writing novels. Not writers in general, not bloggers, not journalists, not poets or academics. Sure, they could all use the app, but it wasn’t for them. A single developer can’t build a generic app filled with features for a multitude of different users.

Once you have this user, look at your product from his perspective. What’s in there that he doesn’t need and what’s not in there that he has to have or he won’t touch version 1? Draw up a plan to tidy up your project, to trim features he doesn’t need and to add the lightest possible features that he must have. Forget about future scaling or delivering version 6 out of the gate. This is version 1 for a specific user.

Build a vision for your product around this one niche user and hold onto that vision.

5. You didn’t move outside your comfort zone

My first two jobs I wrote desktop apps in C++. My first project that turned into a product — PageFour — was a desktop app written in C++. I was a C++ guy who built desktop products.

It was only later as I jumped from company to company as a contractor that I realised how quickly I could pick up new technologies and how valuable that skill was. Different companies, different tech stacks, everywhere different ideas and ways of doing things. Suddenly anything was possible.

Most of us live in a bubble defined by our history and experience. We code in Java or Python, we’re back-end or front-end. We’re tech guys or customer facing. This inability to put on different hats can kill our side projects before they ever become products.

How can you fix this?

You have to step outside the bubble, work in areas that you’re not familiar with or that you think you’re not good at. This means learning new technologies when your project calls for it and stepping into sales and marketing roles as well as writing code. Not a database guy? Start learning. Never built a web service? If your app needs it, you need to learn it. Never talked to customers? Start now.

You need to meet people who populate these other fields, who work and live in the areas you’re weakest. Don’t go to the hacker meetup group, give the marketing group a try. Instead of connecting on LinkedIn with fellow devs in your home city, connect with non-tech start-up founders, with sales and customer centered people, with writers and bloggers.

Take meetings, have lunch. Everyone wants to meet up. Everyone who’s worth the time at least. Talk to them, share ideas, and above all listen and learn.

For your project to become a product it needs more than code. You need to step into other worlds and learn new things. You need to realise that none of these other skills that are required to build a product are any more difficult to learn than the languages and frameworks that you pick up with ease.


To hear more from me, you can follow me on Twitter or on LinkedIn.

Solo Developer

Building an app without quitting the day job — 6am coffee shops and the corporate grind

“If you want something done, ask a busy person.”

Why is it that the guy who tosses in his job to follow a start-up dream fumbles and procrastinates while so many great apps shown on Hacker News are rolled out by someone in full time employment?

Why is it that the starting-out tales of so many great writers tell stories of chiselling out an hour or two here and there, in between jobs and kids, while the creative writing student — who has an abundance of time — never seems to finish that first novel?

Busy people find the time. They know how to use the little time they have to productive effect. Do you want to write a novel? Build an app? Start a business? You can do all of this and keep the day job.

Last year I built a new desktop app called Atomic Scribbler. It was a passion project of mine — a full writing environment for creative writers to replace Microsoft Word and maybe even give Scrivener a run for its money. I built it in Starbucks in the early hours of the morning and in Café Nero after work, spread over the course of a year while working full time contracts in Dublin.

Anyone who’s worked on big corporate projects knows that the pace of development can be glacial, with days assigned to tasks that a good developer could polish off in hours. This slow pace can sap the will and passion from the bright and the eager.

I’d worked in these environments for many years and I knew that the way to survive was to let my creativity and energy flow into other projects. Do the corporate job, but don’t let it define you. Define yourself by what you do before and after the job — make the corporate grind a small part of your day, not the centre of your life.

My day… what it looked like.

I’d rise at 5:30 each morning, take an early tram into Stephen’s Green in the city centre and walk down to Starbucks on the Quays, passing the homeless of Dublin rising from their shop doorways as the delivery trucks arrived.

The mezzanine area of Starbucks was empty at that time of day and would remain so until 8:30am when I left for work. Lap-top out, I’d fire up Jira and start working on the next item on my list, usually a small enough piece of work that could be completed in two hours.

Each day, the same routine. Two hours working in Starbucks then head into the International Financial Services Centre to start work on a Big Data project for a German bank. We were housed in a classic corporate building close to Connolly train station, complete with open plan offices, sci-fi access gates and a single pool table placed in a strategic location so that it could be seen from the street outside.

No one ever used the pool table and everyone wore black shoes. There wasn’t a Metallica T-shirt in the building.

When 5 o’clock rolled around I’d stretch my legs and take a 25 minute walk through the city to Camden Street, stopping at Café Nero where I’d order a mint tea — no caffeine that late in the day, not if I wanted to stick to my daily routine and rise at 5:30 the next morning.

An hour here would see me finish off the work of the morning or start something new. Three hours a day in total, ending at 6:30 — a whole free evening ahead of me to go out with my girl, immerse myself in a good novel, see a film or take long walks up and down the pier at Dun Laoghaire.

Five days a week would see me put in 15 hours on my app — but those were not corporate hours. There were no meetings, no requirements gathering, no liaising with or waiting for other departments. There was no uncertainty — decisions that needed to be made were made and acted upon on the same day.

In 15 hours I achieved more than I would in three weeks at the day job.

Progress…

As the months passed, the app filled out, required features appearing in skeletal form and then popping up fully implemented in the user interface a week later.

Big Data gave way to a web app project at one of Ireland’s leading banks. A new office in the same part of town, interesting for a few months until the project ground to a halt as the many different teams across the company failed to work together.

The Jira list got shorter and shorter and the end was soon in sight. The backlog, which had stretched to hundreds of items, was soon reduced to the final 20 or so that signify a project about to go live: website, license keys, hooking up to a payment collector — all things I’d done before but steps that so many app developers discount.

I paint a picture that looks simple and problem free, but it wasn’t all sailing. Into the mix of long days I tried to fit a social life of sorts — dates with the girlfriend, hill walking in Connemara or Killarney at the weekends, the odd piece of work that the various family businesses required.

And then there was the ugly mug of the lizard brain that kept telling me to stop, to slow down, to take it easy for a while. The closer I got to the finish line the louder my inner demons shouted, doing their damnedest to wreck Atomic Scribbler before it got out the door.

This is the point where so many creative people fall down. They listen to that inner voice and they let it win. They abandon their novel after the first draft or after a single editor expresses displeasure. They stop working on an app that’s 90% complete.

Those final weeks with the finish line in sight are the most dangerous. It’s here that the amateur slips up and starts working on something else — a new project that they thought of only yesterday or a shiny new framework they read about on Hacker News — taking the focus and the passion away from their almost complete app.


And it’s here that the professional powers on through and pushes version 1 out the door, warts and all and to hell with the haters.

As for Atomic Scribbler: it went live, as did versions two, three, four and five over the following months. I’m using it to write this post and it has a community of dedicated followers, growing each week. It fits nicely into my wider portfolio of products for writers.

The work goes on. SmartEdit — a sister app to Atomic Scribbler — is my focus for the coming months. The alarm still rings at 5:30 each morning. There’s a new contract with a new company in a new location. And there’s a new coffee shop — but no mezzanine with a view of the river. You can’t have it all.


To hear more from me, you can follow me on Twitter or on LinkedIn.