Let’s assume you’re happy with the app you’re about to build; that your idea has legs or at least the prospect of legs based on an itch you’re scratching or a gap that needs filling. (There’s an 800 page book in that sentence, but let’s not go there right now.)
How do you start? What do you do you on Day 1?
This is where I was last week. For a couple of months an idea for an app had been floating around in my head. It was to fill a gap I saw in the market for a particular type of developer tool that came to me after working on a greenfield project for a US healthcare company.
For two months I’d been sketching out features in my head and exploring the best tech to use to build the app. Three days ago I bit the bullet and spent a long afternoon implementing the early steps, the steps that while not required on Day 1, have real value down the road when put in place at the start.
I’ve built apps in the past without putting these early steps in place, releasing 6 months of work to an unsuspecting world. No audience, no potential users waiting for version 1, no one in a position to tell their friends or colleagues about it.
It was a wasted opportunity that set me back months in terms of exposure and feedback.
So here’s the afternoon’s work designed to prevent that from happening:
1. Designed a basic logo
I’m not a graphic designer. My logo design skills are almost non-existent, but Canva makes it easy to throw some text up next to an image and call it a logo.
My aim here was rudimentary branding such that anyone in the space I was targeting would recognise the app as belonging to that space. The fire image is recognisable as part of the FHIR database space — which is where my target user lives.
2. Built a one-page website that described the app
Very simple and very basic. I described in a few sentences what the app will do and who it’s for. I can now link to the site from anywhere — Twitter, LinkedIn, etc. While the app doesn’t exist yet, its shadow does in the form of a website.
I used a basic theme that I’d already purchased for multi-site use. No coding was required.
https://sqlonfire.com/ — “Query your FHIR database using SQL”
3. Added a ConvertKit sign-up form to start gathering email addresses
This is the most important section of my new one-page site, and arguably the sole reason the site exists at such an early stage. I want to start collecting email addresses from potential users and interested parties so that when I have a pre-release version I have someone to show it to. If I need feedback I’ll have people in the space to ask. When I go live, there’ll be at least a small audience waiting for it.
No more releasing into a void.
ConvertKit make creating and managing a sign-up form quick and easy. They handle opt-in emails, GDPR regulations, list management, etc. And it’s all free until you hit 1,000 email addresses.
4. Hosted the site
Hosting a one-page site does not require deep thought or careful planning. You don’t need AWS or Azure, you don’t need Cloudflare or Digitalocean droplets. All you need is somewhere to drop a static HTML page.
Keep it as simple as possible.
When the time comes to release your fully featured app, complete with online documentation and payment options, that’s the time to think about where best to host the site so that it can handle traffic spikes and all the complex bits you might have added to it.
I have a dozen legacy websites hosted on a UK server that I pay £100 a year for. Adding another site didn’t cost anything and took about 5 minutes.
Changing the DNS to point to the new host took another 5 minutes, at which point my site was live.
5. Added a free Let’s Encrypt SSL certificate to the new site
Another reason to go with the quick and easy shared hosting mentioned above — a one click install for Let’s Encrypt so that the site has a valid SSL cert. I tried doing this on Azure back in February for a new site I was building and wasted a good hour playing around with Let’s Encrypt before abandoning it and buying a cert instead.
You need an SSL certificate on your site, otherwise Google will penalise you and your visitors will see browser warnings that might turn them away.
6. Set up email on the new domain
My email accounts are all with Fastmail, a paid for email provider that handles multiple domain names and wildcard email addresses. Setting up my new email addresses for the new domain took about 10 minutes.
There were a number of steps involved, such as configuring the MX and SPF records, but it’s nothing I hadn’t done before.
As I already had a Fastmail account, it didn’t cost me anything.
The new one-page site is live now at https://sqlonfire.com/, complete with unattractive logo, brief app description and email sign-up form.
All the steps outlined above took about 4 hours to complete in a single afternoon and cost me $0. Today I’m writing code — starting work on the app itself. But I’m confident that when I have something ready to show down the road I won’t be scratching my head and looking around for users to show it to.
To hear more from me, you can follow me on Twitter or on LinkedIn.
