My wife has a health and fitness brand and when setting it up a couple of years ago, the .com was not available; it was registered back in 2007 or something.

The 2nd best option was the ".life" domain which was kinda relevant to the brand but of course a bit meh like all neo-TLDs.

Every now and then I would check the .com to see if it had become available - and 2 weeks ago I found that it had been listed on GoDaddy auctions after expiring.

The domain itself is a 5-letter .com, so reasonably short and reasonably rare. It's not a real word (at least, not in English), but very pronounceable and with no "weird" letters like X, Q or Z.

I figured that if it kept a low profile it would go under most buyers' radars, and with a prevailing wind we could probably pick it up for a hundred dollars or so.

So I didn't make any bid until a few hours before the end, and that was just in case I forgot to bid later and missed the whole thing (which in retrospect was unlikely since my wife would never allow me to do that).

However, later that evening we went out for dinner with friends and in the fun we actually did completely forget about the auction.

I remembered about it in the car on the way home. It was 10.15pm and I knew the auction ended at 10.*something* but I couldn't remember what.

Panicked, we drove home as quickly (and of course as safely) as possible. On the way we discussed whether worst-case scenario we were willing to spend 100 or 200 bucks on this thing.

We got home with 10 minutes to spare, and the price had shot up to $443 with 4 or 5 other bidders in the fray.

"Well that escalated quickly."

There's an interesting psychology that losing something has more emotional cost than gaining something. Price anchoring also has a funny effect on your mind.

So now the $200 we were willing to spend seemed cheap. The conversation became "what's the absolute maximum we're willing to go up to?"

GoDaddy, like most online auctions, works using proxy bidding. The system will on your behalf automatically bid up to whatever limit you set.

If the price is currently $430 and you set your bid to $500 then the price will jump to $435 and you'll be the highest bidder.

If someone then comes in at $475 the proxy system will automatically raise the price to $480 on your behalf and you'll still be the winner.

So the most sensible strategy in a proxy auction is to decide the most you want to pay for something, enter that amount, and forget about it. Things get real dangerous real quick if you keep adjusting your limit every time you are outbid.

So now we have 10 minutes to actually evaluate how much we're willing to go to.

GoDaddy itself estimated the domain to be worth $3k, but of course that's complete fiction. I checked a few other estimate tools and they came back with numbers ranging from $130 to $400.

I reasoned that if 2 other humans in this auction were prepared to spend $400+ then $300 is a fair base value. That is, if I bought the domain and then changed my mind I could just flip it and get at least $300 back.

I don't see the value of 5-letter .com domains dropping in the future. If anything I would expect short domains to keep rising, because by their very nature there's only a finite supply of them. So owning one would be a fairly safe asset, and the actual cost is only whatever I pay over $300.

Then there is the value that the .com would add to my wife's brand. This is much harder to quantify, but she has huge ambitions for her business and it's hard to argue that a .com doesn't bring trust and credibility - which is super important in the fitness industry.

5 minutes left.

"Would you be gutted if we bid $600 and didn't win it?" I asked my wife.

She immediately said yes.

"800?"

"Yes."

This is starting to get silly. But I wasn't disagreeing with her.

"1,000?"

1 minute to go.

We agreed on $800 and to avoid any last-minute snipers I waited until the last 30 seconds before - to my wife's delight - I entered $1,000. What a gentleman.

Refreshing the page to see what we had done we were relieved to find the auction had risen to just $448. There was no one proxy bidding against us.

But we saw that the auction still had 5 minutes to run! I didn't realise that GoDaddy Auctions adds an extra 5 minutes to the duration if anyone bids at the last moment. My anti-sniping strategy was garbage.

Cue 5 minutes of frantic CMD-R'ing. No-one was coming after us. We'd left them in a trail of dust.

The auction ends still at $448. Whoops of joy, hugs, the works.

I'm a hero, and I only spent half of what it could have been.

(I remembered soon afterwards that the price doesn't include VAT, and as we were paying with a UK card that would slap on another 20% taking it over $500. So I was very relieved it went nowhere near 1k...)

Now we wait 10-15 days (for some reason that I will never understand) for the domain to be transferred, and then my wife's business moves firmly into the .com arena.

And now that I've smashed the $500 glass ceiling, $1,000 will be easy for my next purchase...

It's all about the anchoring.

Thanks for reading! If you'd like more, drop me a follow at twitter.com/hamzaw - I'll be happy to see you there.

If you don't have the correct documentation in place, you might find that you don't even own your product. And generally speaking, no product == zero value.

I learned this lesson the hard way, and it caused at least a 6-month delay in my startup sale (and almost the collapse of the whole thing):

Can you afford that when your time comes? Make sure you have everything in this checklist in place from Day 1.

The good news: it's not too late. If your startup is already established, you should get together anything that you're missing ASAP, and ensure that it covers you from when you started.

✅ Founders' Employment Contracts

You may think "why would I ever do any harm to my own company?", but investors have seen it happen time and time again.

It may not feel like it in the white heat of your startup, but remember: You are not your company, and your company is not you. Whatever work you do in your company is building value for the company, not for you. You are just like any other employee.

So every founder or shareholder who does any work at all for your startup must have signed a contract that includes the following:

1. Assignment of all copyright and Intellectual Property (IP) to the company

2. Non-competition / restrictive covenant clause

3. Non-disclosure agreement (NDA)

✅ Employment Contracts (even for friends and freelancers)

As an early-stage startup you will employ all sorts of people to build your product and company. This might be friends, freelancers, contractors, temps or permanent employees.

I use the word "employ" because even if your friend is doing you a favour for free by writing a software module for you, that module is part of your product and therefore has value.

You might never think your best friend would do you any harm - but are you willing to test that later when there are millions of dollars in the picture? Money does funny things to people...

So anybody who does anything for your startup must have signed a contract that includes the following:

1. Assignment of all copyright and Intellectual Property (IP) to the company

2. Non-disclosure agreement (NDA)

Also, consider restrictive covenants for senior salaried employees.

Employing freelancers or contractors in a foreign country or jurisdiction may add another element of complexity. You may save a lot of money by offshoring, but their local laws may state that without a contract saying otherwise, they own the IP to everything they have developed - which would mean that you don't.

And if you don't own it you can't sell it.

It's no fun chasing down freelancers in another country - 4 years after they stopped working for you - to bribe / ask them politely to sign a retrospective contract in front of a Notary...

✅ Agency Contracts

If you use agencies to outsource design or development, make sure your contracts with them include IP assignment and non-disclosure agreement so that they have no possible claim against you in the future.

✅ Proper use of Open Source Software

I'm sure your product makes plenty of use of Open Source Software (OSS). It could be for small parts of functionality like a calendar UI, or it could be a major fundamental component like Laravel.

You might not even be consciously aware that you're using Open Source Software, because it is just so prevalent now. npm install and boom!

There are 2 main points to consider when using OSS.

1. Ensure that you are using the open source component properly by including it fully intact within your project, rather than copy pasting the bits you want to use into your own code. Unless the licence explicitly states otherwise, this will violate the licence and potentially give the OSS author(s) IP ownership of your code.

2. Make sure that you are only using OSS which has a "Permissive Licence". This means that you are free to use the software in a commercial application. Using OSS which doesn't allow this means that you cannot distribute it (ie. sell your product or company) and would render your product worthless until you replace that software. This could be a big job depending on how complex the OSS is and how deeply embedded it is into your product.

Consider using a service like FOSSA (https://fossa.com) to continuously audit your software and ensure that no-one on your team has started to use a random piece of software or OSS in a problematic manner.

💰 BONUS: Policies and Procedures

A missing policy is technically not going to cause your investors to run for the hills, but it builds their confidence if you show that you have the little things in place too.

Write up short policies and procedures for the following, share them with your teams and try to enforce them as much as possible:

1. Security - include physical security of servers and infrastructure, personal security (use of tokens etc), and principles for security-first software development

2. Audit of data breaches, data loss and security vulnerabilities: what happened; who discovered / reported it; when did it happen; what was lost / exposed; how was it fixed

3. Backups - how are backups taken; where are they stored; how long are they retained for; how are they restored; how long does it take to restore them. Consider running regular restoration tests so you're not caught out if something happens.

So there you have it: 5 critical items that investors or acquirers expect you to have in place. Without them all, your ownership of your product is in serious jeopardy.

Don't spend years and years of blood and toil only to end up with nothing.

And remember - it's never too late to put these in place: see a lawyer ASAP to get things moving properly.

If you like this article, please comment and share, and follow me at twitter.com/hamzaw for more!

Then I used Wix for my wife's blog for a while, but the cost just wasn't worth it.

So now I'm running a Laravel blog on free hosting with AWS free tier for 12 months.

(And after the first 12 months the cost will be less than $6 per month with a 3-year commitment)

Here's how I did it from installation through to optimization - and I'll share some benchmarking results on just how many hits your blog can realistically handle for $0 hosting.

(I'm not going into crazy detail here, just providing a high-level guide. You will need a basic understanding of PHP / Laravel / Linux / AWS to follow along. Feel free to Google, or ask me anything and I will be happy to help you)

🎯 Objectives and Tech Stack

My objective was to get a fully functional blog online - and loading pages as fast as any commercial offering - with zero hosting costs for at least a year.

"Fully functional" means that my wife - the antithesis of a techie - can operate it on a day-to-day basis without assistance (creating posts, categories etc). So sadly "just push your posts to Github in markdown" wouldn't cut it...

The tech stack I decided on was:

1. Off-the-shelf Laravel blog app - I didn't want to spend 40 hours creating a blog system from scratch, and I wanted a tech that I was comfortable messing around with to customize, add features etc.

2. Amazon Web Services (AWS) - specifically their free tier offering: EC2 instance to host the blog, and RDS MySQL database.

3. Cloudflare - I wanted Cloudflare's caching to max out the performance of the blog and and to reduce egress charges from AWS (OK so AWS gives you 100GB per month free, but a just-in-case strategy doesn't hurt...)

💻 The Laravel App

I'm a big fan of Creative Tim, and I had just picked up their entire Laravel collection for a bargain in their 10-year anniversary sale. Included in that collection is a blog app which has a nice clean layout and a pretty comprehensive backend feature set: CRUD for users (including readers who can comment on posts), categories, tags and of course posts. It even includes a full-text search feature.

Although the app I chose was technically a paid solution, you can find many free Laravel-based blogs on the internet, from simple to crazy-fully-featured to entire CMS platforms.

After downloading the app, the first thing I did was strip out all the junk templated content that Creative Tim always helpfully bloats for you: Lorum ipsum text, footer links, placeholders, etc.

I also cleaned up the included database seeders to make them more useful, and connected my local installation to my sqlite database for testing.

I want to re-use the same blog app for multiple blogs (my kids are pestering me to build one for them) so next I replaced some of the hardcoded text with .env variables. This included the site name, homepage hero heading and sub-heading, copyright text, logo URL and social link URLs. I did this using .env instead of database to make it super easy (<img src="{{ env('LOGO_URL') }}"/>) and to avoid DB hits.

There are lots of other hardcoded details like OG Meta Tags that I will fix later.

Finally, I made some small customizations like adding the logo to the navbar and changing some of the wording on the app. I didn't make any changes to the backend (admin panel) code. There's a lot of theme junk there too, but no-one is going to see it yet. I'll worry about that if someone actually signs up as a member...

🧠 AWS

I opened a brand new AWS account in my wife's name to make use of their 12 month free tier. There is actually a ton of stuff they give you to play around with for free, but for now all I want to use is EC2 for a linux instance on which to run my blog, and RDS for its MySQL database.

Set up EC2 Instance

I created a new t2.micro instance with Amazon Linux 2023, and gave it 30gb of gp3 disk space, which is basically what you can use for the free tier. t2.micro is an ancient instance type, with 1GB RAM and 1 vCPU, but it runs nginx, PHP and Laravel with no problems at all. We're not going to run MySQL server on the instance, which helps.

Create a new Security Group with inbound SSH, HTTP and HTTPS access from anywhere. When you have SSL set up later, remove the HTTP access.

Once your EC2 instance is created, assign an Elastic IP to it and log in via SSH (you did save your PEM didn't you...?) Now it's time to install nginx, PHP and your blog.

Here's a quick summary:

1. Make sure OS is up to date:

2.    sudo dnf update
   

3. Install and run nginx:

    sudo dnf install nginx
    sudo systemctl enable --now nginx
   

4. Install PHP 8.2:

5.    sudo dnf install php8.2
   

6. Install Composer:

    curl -sS https://getcomposer.org/installer | php
    sudo mv composer.phar /usr/local/bin/composer
    sudo chmod +x /usr/local/bin/composer
   

7. Install PHP MySQL module:

8.    sudo dnf install php8.2-mysqlnd.x86_64
   

9. I pushed my modified blog app to github, so I needed to install git:

10. sudo dnf install git
    

Then it was a case of pulling my code, doing the usual Laravel stuff (chmod, chown, symlinking storage, etc) and creating my .env file.

It's also time to configure the nginx virtual server. I created a .conf file for my site in /etc/nginx/conf.d. So far I've left the PHP-FPM configuration as default (eg. max workers 50) but I may tweak them later to optimize.

Set up RDS database

Next I created the MySQL database in RDS. In the UI for creating a new database, there's actually an option to set up within the free tier, so it's very simple.

You get a t3.db.micro instance (1GB, 2vCPU) which is slightly less sucky than the EC2 offering, but again it gets the job done. You also get 20GB of storage which is plenty for a blog. Make sure you change the default gp2 SSD storage setting to gp3 for better performance.

Also, make sure you have public access disabled. That means that only your EC2 instance (or anything else in your VPC) can access the database, and it cannot be accessed from outside.

Finally, just set the master (root) username and password (and make a note of them!) and you're good to go. It will take a few minutes to create your DB, and then you will get its endpoint (host URL) from the "Connectivity & security" tab in the RDS console.

Once your DB is created, log in with your master credentials tunnelling via your EC2 instance (remember, there is no public access to your database) and create a new schema and user for your blog.

create database blog;
create user 'blogger'@'<ipaddress>' identified by '<password>';
grant all privileges on blog.* to 'blogger'@'<ipaddress>' with grant option;

Replace <ipaddress> with the private IP address of your EC2 instance. This ensures that only the server itself can access the database.

Finally, configure your DB driver, host, database name, user and password in the Laravel app and run the seeders.

☁️ Cloudflare

I love Cloudflare. There aren't many companies that give so much functionality for free and update their product so often with new features.

Cloudflare gives you performance enhancements and free CDN which I use to reduce AWS egress charges (AWS charges you for all data sent out from your EC2 instance etc S3 buckets etc).

I'm also using Cloudflare's free SSL to give me a lovely long 15 year certificate instead of using Certbot and having to renew it every 3 months.

I created a new Cloudflare account for my blog, but you can add as many domains as you like to a single account.

The first step was to switch my domain's DNS nameservers to Cloudflare. Cloudflare can't help you until they have full control of your domain.

I was expecting to have to set up my DNS entries for email MX records etc. again once the nameservers switched over, but I was pleased to find that Cloudflare had automatically imported them all.

DNS Settings

I created 2 DNS entries for my blog. I want it accessible on the root domain name, and also on www.

So I created an A Record with Name as @ and Value as the Elastic IP address of my EC2 instance. Then I created a CNAME Record with Name as www and Value as the domain name.

Both records are set as "Proxied" which means they can make use of Cloudflare's caching, DDOS protection and SSL.

Performance Settings

Most of Cloudflare's default performance settings are fine, but I enabled a couple of extra settings. There isn't much else to do on the free package.

Go to Optimization -> Content Optimization

• Rocket Loader - enabled

• Auto-Minify - enabled for all media types

SSL Certificate

It's very simple to create an SSL certificate on Cloudflare and use it on your website. The expiry time is up to 15 years, which is far more convenient than using Certbot and hoping that the renewal cron job is going to work every 3 months...

(Note on long certificate expiry: the certificate we are creating here is just for Cloudflare's use; it is not served to the user's browser. Cloudflare will generate a browser cert for your site and automatically renew it every 6 months)

1. From the Cloudflare dashboard go to SSL / TLS -> Origin Server. Click "Create Certificate" button.

2. Ensure the hostnames are correct (you can use *.yourdomain.com to generate a wildcard SSL for all your hosts which is really nice) and choose your certificate validity (15 years FTW). Click "Create"

3. Copy the Origin Certificate and Private Key that Cloudflare generates, and put them into files on your server called origin.pem and private.key . Place them in the etc/ssl directory.

4. Update your nginx conf file to change the port from 80 to 443 and to add the certificates.

server {
    listen 443 ssl;
    ....
    .... 
    ....
    ssl_certificate /etc/ssl/.pem;
    ssl_certificate_key /etc/ssl/private.key;
}

1. Restart nginx service for your changes to take effect.

2. On the Cloudflare dashboard go to SSL / TLS -> Overview and change the encryption mode to "Full (strict)"

That's it! You now have a fully SSL'd up site, with a certificate that will be automatically renewed for the next 15 years.

💨 Performance and Capacity

So now I have my nice shiny blog, and it's running fine in my browser. Time to run some performance tests to ensure it won't fall over if someone else views it at the same time....

I spammed the refresh button on the homepage continuously for over a minute, and the CPU hardly noticed: utilization only went up to 5%:

The 1GB RAM is comfortably settled, with only ~250mb in use when idle.

I stress-tested with 50 simultaneous users using Loadium. They have a free package which gives you 10 tests per month. I programmed it to simulate each user hitting the homepage and then 2 other pages with a few seconds pause between each page.

Even with a ton of php-fpm processes (each process is a single connection, and nginx is currently configured to allow 50 maximum by default) the CPU never really maxed out and the RAM still had 500mb buffer.

I was browsing the site while the test was going on and although each page load was a little bit slow, it was still very usable.

Here are the stress test results:

The RDS database CPU utilization peaked at 22% - still plenty of mileage there.

The site handled the onslaught better than I had expected. My free AWS-hosted blog might not survive a link from the front page of Hacker News, but it should be able to take anything else in its stride. And with better caching I reckon it could handle Hacker News too.

🚀 The Future

There are a few things I want to optimize and improve on the blog.

1. Build more features. My wife had things on her Wix blog like an Instagram wall and testimonials, and it would be super easy to build them on the Laravel blog. Also I will add landing pages for email lead capture - again really simple using Laravel.

2. Try using Laravel Octane to squeeze more performance out of the server.

3. Move static assets to a separate subdomain backed by CDN. Also add better caching, either through Cloudflare, nginx or Varnish.

4. Play around with nginx configuration to improve stress test performance - I'll report back.

When my free 12 months hosting ends with AWS, I will switch the server to an instance like t3a.small (2vCPU, 2GB RAM) and move the database off RDS and on to MySQL server running on the instance itself. RDS is way too expensive to justify using on something like this....

Thanks for reading. If you would like to follow along for more, connect with me on Twitter where I write about building products and startups.