Started with a first bit of coding on the app today! We have to discuss exactly what features we want to build over the coming days and weeks, but I thought I’d quickly start with prototyping a small core component to see if that works as expected.
As an experiment I gave coding in a livestream a try, you can watch it below if you’re interested in a glimpse behind the scenes.
Many apps on the web get very slow when you add a lot of items, and as our app should be as fast as an editor, we want to make sure it works great when you’re adding thousands of tasks or ideas. A technique to speed things up when having to show many items is called virtual scrolling, which I tried to start with today. I’ll also write up a more detailed post about how it works later.
Day 5, and time for a bit more brainstorming about the roadmap and the idea. One of the things on the agenda: naming the app. We’ve picked Thymer.
Picking a name can be difficult but we don’t really have too many magic tips here, it’s a mix of inspiration and luck a name you like is not taken by something similar. Some considerations:
We usually try not to go with something too generic like say apple, although that seems to have worked out OK for them. It helps of course if it’s easy for people to find you when searching on Google, Twitter, and so on. Likewise it helps if you can find it, so you can see where people are referring to your product.
We still like .com, keep it simple.
For a lot of people the browser’s address bar is Google, so they don’t type the full domain but rather the name. That makes it difficult for them to find what they’re looking for when you’re on page 20 in the case of a generic word.
Not that we always do this right, but it helps if your target audience can pronounce it 😉
Some top level domains might come across as spammy. Some might be associated very strongly with a different brand already (which can of course help if you create something like a plugin for another product). Some countries also have some requirements your business is from there, or suddenly introduce extra paperwork. Some are really trendy, which can be a good signal to early adopters; you also run the risk that in 5 years from now it sounds very stale though. Some have all of that (startups which used .ly back in the days)
When in doubt, it seems a trend is to just take two words which form something catchy together. Even if those are generic words, the combined name won’t be generic. SuperList, PhoneMagic, InboxMountain, etc. I think this trend will stick longer than some others (like the early Web2 days names such as Twttr, Flickr) as it’s easy to come up with, pronounceable and there’s a lot of combinations (which helps with most short domains already being taken). Another benefit is people might already get what your product is from the name.
In our case we liked the idea of something new while trying to refer to the product a bit, something related to productivity (getting more out of your day/managing time).
In the end, the name is not super important. It won’t make or break your product as long as it’s not completely terrible.
In our case we still had the domain lying around, unused for like 10 years (a story for another time). For now thymer.com simply redirects to this blog, as we don’t have any visitors yet anyway. We’ll start working on a proper landing page some time soon.
When looking at what features to build, we divide them into roughly 5 categories: core features, long tail features, BS features, checkbox features and anti-features.
Core features
These features form the heart and soul of the product. They make it clear what our vision is. All users of the product will use these all the time. Even if they’re not used by everyone, then all true fans will use them all the time (in the case of power features). If the product doesn’t have these features, it won’t shine, it won’t convey its value proposition clearly. If people aren’t convinced by the product with these features, then the vision behind our offering isn’t compelling enough and we should rethink the idea before building on.
Long tail features
Nobody will buy your product because it has these, but people might eventually leave because it doesn’t.
It does nothing to help you stand out, but people who need (or often, think they do) these features might leave or switch as competitors catch up with your main vision.
There is a very long tail list of these features, and it’s something you can add over time to improve both retention and conversions. They won’t completely make or break the product, and won’t be useful for validating your idea, so there is no need to rush these.
For example, think of how the original iPhone was revolutionary yet didn’t have copy&paste; that simply wasn’t part of what made it so special.
BS Features
As it says on the tin, these features are complete bullshit, laughable even. The product could technically do without these, but adding them helps the business in a different way, by giving it a twist or viral component which helps getting the word out.
Just like anything you write, it’s important to think of who the audience is. And the real audience of a BS feature isn’t the user; it’s an editor at CNN or a friend of the user who will tweet about it.
Spending a day on a BS feature which uses {machine learning, blockchain, chatbots, hype du jour} for no other reason so the press/investors will cover your product has a clear benefit. The product with or without the feature would otherwise be exactly as functional, but instead of being unnoticed, this version of your app does get covered or is fun enough to tell your friends about it.
The number of sales generated for Tesla because of its whoopee cushion “feature” making fart noises is >> 0.
Even better when there’s a viral component to it. We once added a “feature” to a CRUD app where you could add items by tweeting them to us, which other people then noticed. Delightfully silly and completely useless. So obviously people used it and the press wrote about it ;).
Checkbox Features
This one sits somehwere in-between “Long tail” and “BS”. The audience isn’t exactly the end-user, but you do need it to close more sales and expand your audience. It’s a category of features that is relevant for products which have decision makers who aren’t necessarily the user.
This happens often in B2B, and especially B2E (Enterprise) settings. Here, different people typically need to sign off on the approval of a product, all of them with their own ideas of what is important. The more layers are involved, the longer the Excel with “requirements” will become.
Especially if the layers involved won’t actually use the product, the feature requirements might feel strange because you know they won’t actually be used that way. They can be a hard requirement however because of the purchasing process, so your product will simply not be considered unless you can check all the boxes.
If it’s relevant for the market you are pursuing, you can decide to build these in, but in an incredibly minimalistic fashion. That way you can check the box, but nobody is going to care about it anyway. You can even make it a completely manual process. If an “Audit Log Report” is required every quarter to win a $$$ sale, you can manually query it from the DB and send it in a PDF. Boom, feature checked.
Anti-Features
Other than the four categories above, these we need to avoid at all cost! In other words, we need to keep a not-to-do list and avoid falling in the trap of building anti-features.
An anti-feature is something we add to our product which would take it in the wrong direction. Not only does this take precious time away from building stuff that matters, but it can trade good customers and leads for an audience which is not relevant to the product.
It harms both the product and the marketing. It dilutes the vision of the product and makes it look like something it’s not. It also makes the product harder to use for your real audience.
Most often, the anti-features end up being built because a really persistent customer really “needs” it. Most likely they’re not even a customer yet, and just as likely they only think they need it.
Especially when starting out, with very little to no revenue, it can be hard to say no and tempting to build it in. Resist this, because it might turn you on a path of becoming a de-facto freelancer for individual clients and endanger your entire product.
Of course you won’t always know when something is an anti-feature. It’s tricky because some of them are easy to mistake for ‘Long tail’ features (but hardly ever for core features!). A good rule of thumb is that if you have doubts, they’re probably justified. If you keep hearing the same feature requests or complaints about the product over and over again, then you’ll learn automatically that it’s valuable enough to move to the nice-to-have Long tail list.
Update @ Day 21: the landing page is now live! Check Thymer.com for more details.
It’s day 3 of 80, and the decision on what to build as a startup in the remaining 77 days has been made! As we summarized here, it will be a web app (SaaS), and it’s going to be a… brace yourselves… to-do list app. Haha, yes, well, kinda.
Building apps for tasks and notes sound like a cliché at this point. The last internet census counted 68,482 to-do apps. It’s even become the “Hello World” example for web framework tutorials. So perhaps it’s only fitting to build this as the ultimate example of how to build a startup! We’re planning to build a real product though. And as we outlined yesterday, we only think an idea works if it has a “first”. So we want do try a new approach in this category:
We’re going to build an editor/IDE1. Except it’s a text editor specifically designed for tasks, planning, and thoughts; for makers to manage creative work.
Using an editor interface for managing tasks and planning feels like a much more logical fit to us than the existing categories, the classic to-do lists and kanban boards.
The most obvious symptom of the problem with the existing apps to us is a “todo.txt” on our hard drive. We know we’re not the only ones who keep falling back to just jotting down notes in a text file or (virtual) stickies. With text, you can write down tasks or thoughts as fast as you can type, indent as much you want, collapse/expand sections, select, copy/paste or move a bunch of text somewhere else, add whitespace… format it any way you like. All these features are essential for organizing thoughts.
Having to decide what needs to be a project vs a task vs a subtask when you’re just typing out thoughts, having to click buttons, using an interface that gets slow when you enter more than a 100 items… it’s just too much friction and disrupts the creative flow. So it’s great to have all these fancy apps, but in the end, we end up with a todo.txt, again. And although a text file works, there’s no way to visually organize things, add any structure or links, collaborate in teams, drag things around, filter or schedule things. It’s just plain text, after all. So we can never find anything back and after a while declare text file bankruptcy and start over.
We want to have the best of both worlds. And we think that looks like an IDE. When you think about it, IDEs have similar features you need in a todo app built-in: things like syntax highlighting, collapsing indented blocks, keyboard command palettes, and plugins. Instead, our “IDE” will be for anything related to organizing creative work: commands, auto-complete and highlighting for things like dates and priorities. With support for scheduling, references, split-panel views, and being able to drag things around. And like an IDE, “hack-ability” in terms of plugins is a big thing too, because good tools should adapt to how you like to work.
We could talk a lot more about other cool properties this kind of system would have but that’s the idea at its core.
In the next post we’ll recap why we think this might work as a startup to build in 80 days.
[1] For non-coders: Integrated Development Environment, fast and powerful editors and related tools for programmers
Much has been written about picking startup ideas. Although a good idea won’t be a guarantee for success, of course we want to avoid picking a bad idea which sets us up for failure even before we start.
As part of picking an idea is identifying bad ones, we wrote down some of the points we check our ideas against to see if we’re not too quick to jump onto something which isn’t a good fit. Not everyone will have the same criteria, and in our case it’s mostly about bootstrapped software business, but here goes:
1. It’s not super relevant for us
If we can’t even convince ourselves we’d really want to use this, how would we convince others? How do we come up with improvements and novel solutions, if it’s a problem we don’t want to solve for ourselves? How can we find and interact with our audience if they’re nothing like us?
Just as important, how are we going to stay motivated and care enough to make it a success when inevitably there will be some roadblocks along the way. Everything feels like an uphill battle if you don’t think an idea is really interesting, matters enough, and is fun to work on. When an idea does fit, working on it feels like going on autopilot.
That rules out going for that “I have an amazing idea!” you read about somewhere else.
2. It doesn’t allow us to run the business we want
Besides the problem space itself, the idea must support running the type of business we want. Can we use the skills we enjoy using to make a difference in this space? What other aspects of running a business do we find important (for example, being able to work remotely, not having to raise capital, and so on).
Likewise, what are things we really hate doing? There are always tasks that aren’t fun, but if the success will depend on us primarily doing exactly those, we’ll likely not do them on autopilot as we should and risk not moving forward fast enough. It’s better to be honest about this beforehand, as now is the time to pick an idea which is fun to work on by design. No use in trying to launch an idea for the enterprise market when you have no interest in sales.
3. There is no part of the product that’s a “first”
Not building something that’s original would violate #1 for us. But even if you enjoy building a “me-too” product, the internet will be too saturated to care. Some things might have worked five years ago but not anymore. It’s easier to be first (some things even just work once).
No product is 100% original in every aspect of course. In fact, if the category of product doesn’t exist at all yet, that’s often a red flag. But something about it needs to really stand out in a fundamental way. Think about how fans of this new idea’s approach would never want to go back. And how your product did it first.
Just like the product, the marketing (or anything related, like business model) needs a first, too. It’s not the web of 20 years ago anymore. There’s more content competing for attention than ever. Ads are dead (prohibitively expensive for many bootstrapped businesses). Established Marketplaces (like App Store or G Suite) are saturated. Provided you execute well, the chances someone buys from a competitor is not because their product is better, it’s because they don’t know you.
It’s more important than ever to stand out, but there are many ways to do so. For example, the first community around X, the first SaaS version of X, the first privacy-first version of X, the first open source version of X, the first freemium version of X, the first premium version of X, the first to use a channel for X. Everyone needs a thing.
4. We don’t know who to charge for it
Even by filtering ideas, we don’t know for certain if it’s really viable. Interviewing potential users, asking friends, getting “leads”.. It’s all nice, but the only validation is validation by credit card.
So whether people will really pay is what we need to test. But we must at least have an idea how to get users to our checkout form. If we either don’t know who the audience is, we don’t know how to find them, or we can’t charge them enough (depending on our $ARR goal), then it’s time to go back to Start and don’t pass Go.
Lastly, and this is related to #3 above, we also want these initial customers to be real fans. The idea must support creating real fans so we get vital feedback and organic growth. Obviously we don’t know yet if our idea will have fans, but it’s just as obvious that certain classes of products will never have fans, but simply users (i.e. don’t start a paper company).
5. The V1 of the idea isn’t simple enough
The only way to truly validate the idea is to charge for it (#4), and that most likely means building a V1. What’s possible depends on resources like knowledge, budget and time of course, so it must be simple enough to fit those constraints.
Another advantage is that a simpler product is often faster to sell than a large integrated solution which requires numerous stakeholders to sign off on. It’s also easier to explain what is and convince first potential fans to try it out. As building and testing a new idea is already difficult enough, keep things as simple as possible.
One category in particular to be wary of is “broad product ideas” with existing competitors. Where a deep product solves one particular problem really well (digs deeper than the competition in one aspect), a broad product is useful because it does many things in an integrated way. For it to be truly unique and better in some way (see #3), its V1 needs to do be either broader than the competition, or at least as broad and deeper. Both outbuilding and outselling complete existing platforms from day 1 is a bad idea when bootstrapping your first business idea.
Okay, bit of an aside, but hey we share what we’re working on, including distractions. While writing our first posts, I thought it would be nice to have some previews show up when posts are posted on Twitter or whatever. So I quickly hacked something into our WordPress blog to automatically generate an image which social media like Twitter will use as a preview for the URL.
The image shows the 80daystartup logo with the title of the post dynamically added into the image. The twitter/social card for this post is:
assets/gen_social_img.php:
<?php
// Generate twitter large card: 1200px x 630px
// Example https://80daystartup.com/wp-content/themes/theme80/assets/gen_social_img.php?string=some%20string&h=md5('some string'+salt)
$imgPath = '/var/www/html/wordpress/wp-content/uploads/card_base_image.png';
header("Content-type: image/png");
$image = imagecreatefrompng($imgPath);
$color = imagecolorallocate($image, 0, 0, 0);
$text = "Creating A Startup From Scratch in 80-Days With A Long Title";
if (isset($_GET['string'])) {
$text = $_GET['string'];
// not super important, but just to prevent everyone making their own ;)
if (md5($text . "YOURMAGICSALTHERE") != $_GET['h']) {
$text = "";
}
}
$text = wordwrap($text, 25, "\n", TRUE);
$fontSize = 60;
$y = 380;
$angle = 0;
$font = '/usr/share/fonts/truetype/lato/Lato-Black.ttf';
$bbox = imagettfbbox($fontSize, $angle, $font, $text);
$center1 = (imagesx($image) / 2) - (($bbox[2] - $bbox[0]) / 2);
$x = $center1;
// Add the text
imagettftext($image, $fontSize, $angle, $x, $y, $color, $font, $text);
imagepng($image);
imagedestroy($image);
?>
In header.php, each post then dynamically generates a call to gen_social_img.php, which will return the image:
Just to end on a note more relevant to today’s topic of looking for startup ideas.. in general, plugins to solve issues you run into and enhance existing software (or other products) are also interesting startup ideas. It’s an existing market and you’re usually not the only one running into a certain issue.
Day 1! Last week, as a preview, we wrote a bit about how we prepared this site (you can read the entries at Day -1 and Day 0) and now it’s time to finally get started. The first important part is the idea of what to build, so today we’ll post some of our ideas about.. ideation.
As a quick intro though, I thought I’d also quickly mention all the stuff we’re not going to worry about. Although it might seem obvious, I think it’s good to mention because I often read people worry about all kinds of aspects before starting their first business, which once you’ve actually built something you know just don’t matter. The beginning is a very fun/creative process, but it’s just too easy to come up with reasons why something wouldn’t work and then not get started:
Lack of “business experience”. You don’t need a fancy company structure (nobody succeeded by having more companies than customers), you don’t need to write BusinessPlanLastVersion3.docx, know what SWOT means or start by printing business cards. That’s just how it works in movies (and in school textbooks maybe). All the stuff which actually matters you can learn on the fly.
I don’t have “a network”. Neither do we, and it’s very very rare to have people actually care about what you’re doing right from the start anyway. Chances are nobody will read these initial posts, or not until we’re much further in the process. You can only get the ball running by putting things out there, so just start.
There’s not enough new things left to interest people. That’s why it’s so great to launch online businesses today. If this is a worry then people vastly underestimate how big “the internet” actually is. Even a tiny niche idea in the context of billions of people will get you some initial fans.
“That’s not how things are done”. When we bootstrapped our first web business, I think quite some people we knew just assumed it wouldn’t really work out, because it was different from all the examples they had seen and were told about as things proven to be “possible in life”. If everything worked like this, nothing new would ever be tried. As long as you don’t break any laws of physics, no reason not to try it because you assume it’s impossible.
What if it’s bad and fails? Only way to improve is to start. We have plenty of experience with code and business aspects of online startups, but there’s always new developments and many things we haven’t tried. The idea for 80daystartup is going to involve lots of writing, maybe things like podcasts, who knows what else. All of which I have little to no experience with, so it’s very likely I’ll be very embarrassed looking at all the writing a year from now. Which is great, that means progress!
Anyway, enough with the worries ;). Next step, ideas!
Just like yesterday this is another meta-post where we’re going to write about how we’re building the 80daystartup.com site itself. Once the site is done we can really get started with Day 1 of the 80-day startup challenge and explore ideas of what to build as a product.
Yesterday we looked at the logo and design for this website. The next step is setting up the backend for the site, which we decided we would just use WordPress for to keep it simple. We need to get the design we’ve created yesterday into WordPress somehow, with a custom theme or something. I don’t really have a lot of experience with WordPress, so let’s just dive in and look at how all of that works first.
Server & WordPress install
There are plenty of hosted and ready-to-go options for WordPress. We simply took a Linux VPS provider and installed the latest WordPress on it, nothing too special.
Once we get to the more interesting part of setting up a server for our app later on, we’ll of course share all the details of the config and server setup. Whatever servers we might need for the product later on will be completely separate from the 80daystartup.com WordPress server anyway for security reasons. Even though we enable all the default security measures like a firewall for the WordPress server, we’ll consider it as completely untrusted. We always call servers like these radioactive: everything they touch is also considered untrusted, because you don’t want to be one WordPress exploit away from leaking customer data.
Site structure
With a standard WordPress install running, the next step was to make it look and work like we intended. I first made a list of things we want to show on the site:
The front page we designed yesterday as a welcome page. Here we explain what the 80-Day Startup is, the current status in the progress bar, a FAQ with more details and navigation.
We also want all our “posts” to follow the same design template (footer, heading links, CSS, and so on).
A “Day” entry. We want something like 80daystartup.com/day-42/ to show all posts for “Day 42”
We also want something like /days/ to show a list of all days. The days will also be linked to from the percentage bar (each block is a day), but a separate page with all links spelled out seems helpful.
Although most entries are probably browsed by day, we also want to have a list of topics which we’ve talked about so far. So something like /topics/ will show a list like “marketing”, “servers”, “press”, “javascript”, “VAT handling”, “launching” and so on. Clicking on a topic will then show a list of posts where we talked about that topic across all days.
A “Subscribe” form where people can leave their email address if they want to receive updates, along with an RSS link if people want to follow the blog that way.
A Search function
Other default pages like a 404
It seemed Themes in WordPress are the more flexible way to customize everything the way you want to I started looking into those.
Creating a custom WordPress theme
I found https://www.dreamhost.com/wordpress/guide-to-developing-a-wp-theme/ as a resource on how themes work. Apparently there are WordPress Starter Themes we can use as a base, which include all the minimum base files and minimal CSS but without any styling yet, so we can replace the contents with the logic we want.
Base Theme
I followed the instructions to use https://underscores.me/, which is a very handy tool to generate a new, empty, base theme. Clicking “generate” gave a zip for the base project. Unpacked it into a new theme directory, theme80, which I added to the themes directory (wordpress/wp-content/themes/theme80). With the empty base theme “installed”, I activated it under Appearance > Themes. Everything now looked minimal without any style, so that worked.
With a better understanding of what the inner rendering loop looks like, I mapped the structure we wanted to WordPress concepts/files in the theme:
The welcome frontpage goes into front-page.php, which should overwrite anything else that it might otherwise render as a main page.
Because WordPress already has a concept of categories, that seems a great fit to map to our “days”. So we can build the overview of all posts in a day by modifying category.php.
Likewise, we can reuse the existing concept of tags for our topics. That way we don’t have to build a bunch of custom logic, and a page can already have multiple tags, which we also need.
The concept of a “Page” (vs post) we can use for our other top-level pages such as “List of all days”, “List of all topics” and Search page. It seems we can just create a Page in the admin interface, and WordPress will look for a page-<slug-of-Page>.php to render any custom template for the page. We’ll simply create an empty placeholder page in the interface, and put everything there is to render in the .php file.
To make sure we can test all these concepts, I added a bunch of dummy examples for all those elements: a bunch of example blog posts in different “Day” categories, with different tags (topics).
I then created the top-level “Pages” in the interface: “Welcome” (/), “Topics” (/topics/), “All Days” (/days/) and “Search” (/search/). Using the Settings > Permalink options, we can also change the URL logic so that all entries for a day will be available under /day-X/ and topics under /topic/X/:
Use “Custom Structure” https://80daystartup.com/ %category%/%postname%/
Under “Category Base”, entered ‘day’. That way when we navigate to a category, we don’t see /category/day-1, but /day/day-1.
Under “Tag Base”, entered ‘topic’ (so we see /topic/server/, instead of /tags/server/)
Then, to set our static “Frontpage” as the homepage: Appearance > Customize (shows theme editor), clicked “Homepage Settings” in left bar, selected “A static page”, selected “Welcome” (the page created above).
Custom PHP
Time to fill out the .php files. Because we’re not creating the theme to make it reusable on some other website, I decided to keep as much of the design in the theme itself, rather than using WordPress features to render them. For example, the navigation menu is simply hardcoded in the header.php, instead of using the “Menu” setting. This way we don’t have to worry about any future Wordpress updates to the settings and we can simply grep the source so we don’t need to remember in what screen we can find which setting (there’s quite a few different settings between the General settings, Plugins, Tools, Theme Editor, etc etc). The main files to edit were:
functions.php: general functions for the theme. Wrote a little bit of PHP, like a helper function get_current_day() to find out what the current “day” this is. For this we simply look at what Categories have posts in them, parse the category names (“Day NN” -> NN), sort them, and take the highest number (so NN is a number between 1 and 80, and <= 0 means we didn’t start yet). Also wrote a function which renders the progress bar based on what day we’re at, including an overlay card with more details, to be included on the welcome page.
front-page.php for the welcome page. I put the HTML of the design we created yesterday in here.
style.css: all the CSS of the design from yesterday. In addition to the custom design, adjusted the CSS of the standard WordPress navigation to blend in with the rest of the design. Added a bunch of display:none’s to hide parts we don’t care about and simplified the design overall (remove the sidebar, just use one large center column, larger font, and so on).
footer.php: the footer from the design we’ve created yesterday, so it gets included on every page.
header.php: top navigation links when not viewing the home page.
page-search.php is simply an empty template except for <?php get_search_form(); ?>, easy.
category.php: the overview of posts within a day. Started with a copy of archive.php and replaced the wording regarding “Category” to “Day”. Customized the headings to fit well with the rest of the design, added information about what day this is and included links back to the current day if we’re rendering an older one. Also added some logic to show placeholder text + GIF in case we don’t have an entry for the day yet.
author.php: like category.php, but for showing all posts by author. Added some HTML to show a nice header with avatar + bio/links.
page-days.php: the List of Days page. Added logic to render all categories with posts in them, which then link to /day-X/.
template-tags.php: customized some date and time formatting here, to give posts a cleaner look. Since we’re going to have multiple posts on a day, and we already show a large header for the day itself, we don’t need all the additional date details for each post.
page-topics.php: PHP logic to render a list of all tags with posts in them.
404.php: custom 404 page with mandatory meme gif.
Also simplified some of the default sections like the comments section (comments.php) and details of a single post (single.php).
(Social) media assets
I also added some images to use as social media tags in the <head> section in header.php, like the <media og..> tags which are shown in tweets when somebody shared the 80daystartup.com URL on Twitter. To create images like that, I simply used good ol’ Inspect Element in Chrome and set the browser’s dimensions to 1200px630px (and added overflow: hidden to the body). I tweaked the font sizes a bit to fill the screen, and then used Capture node screenshot on the body, and boom, social media preview card:
I used a similar technique on the hourglass “8” to create a Favicon.
Subscribe form
Finally, I had to hook up the “Subscribe” form design from yesterday to actually do something. Ideally we just want something that sends an email newsletter around based on the RSS feed, as a weekly digest or something. All we need is the ability for people to subscribe with double opt-in (to prevent spam) and do RSS to email. This seemed surprisingly hard to find. Every newsletter app is a complete “marketing automation platform” thingamajig, which we don’t really care about.
It’s also not something we want to spend too much time on and compare a hundred solutions, so we’ve just decided to give an app called MailPoet a try. They have a WordPress plugin I installed, which then adds an option to create new forms under Mailpoet > Forms. I clicked New Form, clicked “Skip, start with a blank form” under “Select a template” and set the button label to “Subscribe”. Under Form > Form Placement, I selected “Shortcode & Other”, got the PHP code and put this in footer.php. In order to make the form blend in with our design, I simply added a bunch of CSS overwrites in footer.php until it again looked like the subscribe form we designed yesterday.
Other settings
The last changes I made was turning off all the pingback/notification logic under Settings > Discussion, I don’t think we need it. I also installed a plugin called “Code Syntax Block”, because it seems the default Code block has no syntax highlighting.
Backups
The VPS provider also provides backup snapshots, so that will be good enough for this blog. We also created this little backup script which runs once a day, just to have an easily accessible history of older versions (it keeps copies of at most 31 previous days):
#!/bin/bash
dom=`date +%d`
# backup all web/wordpress files (follow symlinks)
cd /var/www/
tar zcfh /home/backups/www_${dom}.tgz .
# backup database
mysqldump -u root --all-databases | gzip > /home/backups/db_${dom}.sql.gz
echo "backup created for day ${dom}"
~
With the site set up, I guess we’re ready to start the real work at Day 1!
Okay, so the plan is to build a software startup in 80 days from scratch. On Day 1 we’ll probably begin by exploring an idea of what to build.
For now, we first need a website/blog to share our progress. As we’re building everything in public, we might as well go meta and write about how we make this website before we really start. This post is the only one that isn’t really live, because we had to put up the blog before we could write this post, so we’re calling this day -1 🙂
The idea for this site
A year or two ago, we were thinking it would be fun to share some things we’ve learned while building our SaaS products. In the end we never got around to writing anything. There are so many books on the subject by now, so we just weren’t really sure if anyone would really care about this from two unknowns.
Then last summer we got an idea: how about we set ourselves the challenge to build a new business from scratch, while sharing exactly what we’re doing. This sounded way more fun and different from yet-another-blog-or-ebook. And we get to build something cool (hopefully!) in the process.
Beach + time is always a great recipe for new ideas: some early sketches I jotted down during a tripin summer
After some doodling, the idea really took shape: there should be 1) a limited time frame for the challenge, 2) we would write update posts every day, 3) we would “open source” everything, and 4) the goal should be a real product with real customers, not just a side-project.
Name and domain
We decided 80 days would be a nice amount of time. In working days, that’s roughly 4 months. Short enough to keep it interesting and challenging but long enough to get some actual work done. So eighty-something. We thought of words like build, maker, product, project, but thought startup would be best. It’s kinda catchy, and also reflects the idea we want to build a real business, not just a demo (and honestly, startups gets more press than projects 😅).
Nobody had claimed the domain yet and we also didn’t find something similar. Lucky break! So we registered 80daystartup.com for around $10. We didn’t have time to work on it for a while, so it’s been sitting there.. until now.
Website
The main function of the 80daystartup site will be to share updates like this about what we’re building (along with some screenshots, videos, embedded tweets, code, and so on).
As tempting as it was to make yet another tool for this, just using WordPress seemed good enough. We did decide to make some sort of own template though, just to make it stand out a bit and we can have different sections for the FAQ, days, topics and so on.
So, step one, design a nice landing page with a logo and visual style for the project. I got started by just coding into a plain HTML file. It’s quick to get some simple design going that way without having to worry about how WordPress themes and templates work yet.
Look & Feel
To design things I usually start by just sketching out some stuff on paper. My initial “feeling” for the site was something 8-bit / retro. Somehow that resonated well with the concept of indie developers for me (possibly from indie games) and the project also has a sort of game/challenge elements to it (time limit, will it succeed?, and so on). Maybe the fact that the name starts with “80s” was another reason.
Logo
For the logo, I was thinking how “80DAYSTARTUP” could be represented by some symbol. So I tried just sketching the “80” part.
The 8 kind of looks like ⧖.Which kind of looks like ⌛️, i.e. an hourglass. And an hourglass fits perfectly with the time-limited element of the project.
It makes sense then to have some pixelart logo to go with the 8-bit/retro theme. I thought of maybe having the hourglass “sand” in patterns of ones and zeros, but that doesn’t really fit with a low-res 8-bit logo (too much detail).
I know, right. Move over Picasso..
I googled a bit for a retro font to write the 80DAYSTARTUP heading in. I found a font called “Emulogic” but that seemed very old and didn’t really have clear licensing details. I then found there’s a font that looks a lot like it, hosted on Google Fonts (https://fonts.google.com/specimen/Press+Start+2P).
Logo part 2: the hourglass
I wanted to get an hourglass icon in “pixel art” style, but couldn’t really find anything suitable, so I tried to draw something.
After some searching I found a cool pixel editor called aseprite.org, which seems perfect for drawing something up. It’s about $20, which seemed well worth it to create a nice logo.
It took me around 10 attempts and a bit too much time maybe, but eventually got the style I was looking for. I think it looks recognizable as an hourglass but in a similar style as the “8” in the retro font.
Because I needed the logo as a vector image (so it can scale accordingly), I found a “PixelsToSVG” tool (https://cdpn.io/shshaw/debug/XbxvNj). Didn’t even need it: turns out Aseprite can already export to SVG!
index.html
With the logo ready, I started with an empty HTML file, added a heading, and replaced the ‘8’ with the SVG.
A cool effect I like to color things up a bit is using masks and clip paths. With the background-clip: text option we can give the letters a background from any image. That way we can get an effect similar to giving heading text a gradient color effect, but with more complex textures.
I decided to search Unsplash for a nice colorful texture. I came across a bunch of photos with purple neon lit cityscapes, which has this retro-future feeling to it, so purple seemed like a good fit. Searching for something like “abstract color” I found this image at https://unsplash.com/photos/8CItx_c0CkI:
Our hourglass icon didn’t get any background, because it’s not text so the background-clip trick doesn’t work. For SVGs we can use mask-image instead to get the similar effect.
With the logo done, it was time for some more styling to the “hero header”, which is the first part of the site most people will see. Some sort of pixelated pattern sounded like a fitting thing to try. A great resource is http://www.heropatterns.com/, which makes it easy to generate all kinds of pattern, including something blocky/pixelated pattern.
It’s a nice pattern, but I had something more pixel-y in mind, like as if it was drawn by a paintbrush tool, so I drew that in the pixel art editor:
.. and then used it as a mask over the hero element with the pattern background:
Then I looked into adding a bit of animation to make it more playful. Something with the hourglass being turned over seemed like a good place to start. First, I made the hourglass icon rotate. Instead of a fluent motion, the steps keyword gives it more of a tick-tock clock feeling.
We also needed a .PNG logo file of the end result: a slightly rotated hourglass 8 and the “0daystartup” text together, so we could use it on other pages. One tricky part here is that we need to make sure we get an alpha-transparent background, otherwise the logo file wouldn’t work on backgrounds with different colors (or dark mode).
Safari’s Web Inspector is a great tool for this: simply click Inspect Element on the <h1> tag, right-click on it in the DevTools, and then click Capture Screenshot. Safari will then take a “screenshot” of the node, with an alpha-transparent background (the current Chrome version gives you a background color, so we can’t use that).
Progress bar
Because the idea of the 80-day startup is to post about our progress every day, and then launch on day 80, it sounded like a fun idea to add a progress bar. That way people can see us get closer to our goal, and it’s clear what the idea is. Staying with the retro theme, I had to think about those old-school MS-DOS installers and their progress bars. I loved watching those setup.exe programs as a kid 🙂
Back then they simply used ASCII characters like ▓ and ░ to draw the bar, so why not use those again for that retro look! Another nice thing about drawing the bar this way is that we can make every bar character a link. So we can have 80 characters, and each character will be a link to the entry for that day!
Putting it all together and adding styling for the bar, it looks like this (the arrow I actually “drew” with Mac’s Preview app, because why not).
Made the footer in a similar fashion to the elements above. Also added an input + button for the sign up form (which doesn’t do anything yet).
Responsive
The last part to look at was making the design responsive so it looks good on smaller devices. By trying smaller screen sizes with Inspect Element > Toggle device toolbar, most parts already looked good by just using a 100% width. I then took the lazy approach of manually patching a bunch of CSS rules in Inspect Element until it looked good, which was mainly forcing a bit of more height for the hero header, adjusting the font sizes somewhat, and patching the absolutely positioned “info card” on top.
Except for a few lines of CSS, the only part which took a bit more time was getting the progress bar right. We can’t completely size it down, because all individual blocks need to stay large enough to remain clickable/touchable (as each block will link to a day entry). As an alternative, I wanted the progress bar to break in evenly sized lines instead. So instead of 80 blocks on one line, show two lines of 40 block characters, or four lines of 20.
The quick and hacky way without having to introduce a bunch of new containers was to simply add line breaks, which become visible depending on the screen resolution.
Alright, that’s enough for the design and frontend for now. We’ll look at the (WordPress) backend tomorrow.
@wcools
