DEV Community: farez

Ship Indie Projects Fast, and Securely

farez — Thu, 24 Oct 2024 17:36:12 +0000

[This post has a video]

If you’ve been keeping up with indie hacking goings on, you’d be aware of the Shipfast and Marc Louvion drama. I’m not here to analyse or take sides. And Marc has already responded gallantly.

But I want to say a few words about our responsibility as entrepreneurs and service providers. (BTW this is coming from over 20 years of professional software engineering experience, 5 years of building startups and a PhD in computer network security, so I’m not talking our of my arse).

Security is important

If you’re running a restaurant, would you want to make your customers sick from your food? If you’re selling cars, would you sell cars without locks?

It's the same with software. If you're building something that handles customer data, there’s a responsibility to ensure it’s safe. The good news is, you don’t need to be a security expert to do that.

"But you need to ship fast, fail fast, get traction…" Yes, solid advice. But security often gets left behind in the rush, especially when you’re a solo founder. Security seems like a huge, overwhelming topic.

It’s not Difficult

Securing your app doesn’t have to be hard. In fact, with modern frameworks, security is baked in.

Thousands of developers hours have gone into building, and securing, popular open source frameworks like Laravel, Django and Express. And these have been battle tested in the field against numerous attack attempts. Security holes are constantly being discovered and patched.

With modern frameworks, you don’t even have to think about security because they are often a core component of the framework.

With Laravel, for example, you get these security features out of the box:

Form security: Laravel adds tokens to forms to Cross Site Request Forgeries.
Password hashing: Even if a hacker gets into your database, they can’t see the passwords.
Third-party logins: Want users to log in with Google or Facebook? Just enable it.
SQL Injection protection: Laravel uses parameterized queries by default, protecting your database from SQL injection attacks.
API Token authentication: If you’re exposing an API, authentication using tokens is already taken care of.

Most of these are things you don’t even have to spend a second setting up, but they save you a ton of headaches down the road.

Starter Kits and Security

A lot of indie hackers start with pre-built starter kits. And these can be great—they help you launch faster and focus on what matters. But one thing many of us don’t think about is whether these starter kits are secure. And honestly, it’s not your fault. Most of us aren’t security specialists, and neither are many of the people building these kits.

The truth is, security hasn’t always been front and center in our community. Many high-profile indie hackers have said they don’t even worry about it until they’ve gained traction. That makes sense—time is short, and the pressure to ship is real.

"But Pieter Levels said..."

You’ve probably heard stories like Pieter Levels’s—building entire businesses with just a single index.php file.

It’s inspiring, and it shows how much you can achieve with minimal resources. But here’s the catch: even those single-file setups need to be secure. Don't be fooled—Pieter secures his scripts.

And you're not Pieter Levels.

For my projects, I use Laravel, Tailwind, MySQL, and Nginx. It allows me to ship fast and have security built in. And it’s free.

But this is just my preference. And there are plenty of other great options out there.

For example, if you're more into JavaScript, you could use, Node.js, Express, and SQLite. Or if you're more comfortable with Python, you could use Django, FastAPI, PostgreSQL, and Gunicorn.

These tools are also widely used, secure, and have strong community support. The key is to pick the stack that works best for you and your skillset, while ensuring that security is a priority.

Takeaways for Indie Hackers

Buy starter kits if you want. But don’t overlook open source frameworks. It’s secure, it allows you to ship just as fast, and it’s free.

As indie hackers, we have a lot on our plates. We’re trying to build, launch, and grow—all with limited time and resources. Security can feel like a huge burden, but it doesn’t have to be.

No need to be an expert, no need to reinvent the wheel. Just use the tools that are already out there, and focus on shipping without drama.

Let’s keep pushing forward, moving fast, and yes, staying secure.

Have questions?

Want to know more about securing your app? Or have a question? You can reach me on X or LinkedIn.

What OpenAI’s latest updates mean for AI builders

farez — Tue, 07 Nov 2023 04:09:46 +0000

Do we still need embeddings?

GPT-4 now has a 128K context or “more than 300 pages of text in a single prompt”. And you can now upload files with the API. This means for most “chat with document” cases, you can just upload the file wholesale and ask questions.

Or you can feed all your data to the new Assistants API and let it do the retrieval. You just give it your file and it can do its own vector search on it, if required. Furthermore, it remembers all the chat history, so you don’t need to save that either.

This also simplifies your architecture.

Better math

Assistant API can now run sandboxed Python. Math hasn’t been GPT’s strong point until now.

Combine this with retrieval, and you have a really powerful data analysis tool.

Multimodal

You can start building true multimodal apps with new Vision, DALL-E, Text-to-speech endpoints.

Read a table then output a chart. Read an image and read a summary of it out loud. Brainstorm design ideas verbally and have it iterate on a design.

Cheaper

GPT-3.5 and GPT-4 are 3x cheaper. Fine tuning is 4x cheaper.

If you’re a SaaS competing on prices, I think this is the time to reconsider your business model.

But this is great news for bespoke builds. The ongoing maintenance cost for your clients will be much more attractive.

Faster

Multiple function calling in a single message means less round trips to the API. This is great for the user’s experience.

And the rate limits have doubled GPT-4.

More accuracy, more reproducible

There’s a new “JSON mode” that will instruct the API to always return valid JSON. This is really useful for returning structured output in a chat session. JSON mode is available in GPT-3.5 too.

And there is a new “seed” parameter to make outputs reproducible. Useful if you’re integrating your data into a workflow that requires a high level of repeatability.

What this means for our own AI app, bunni.ai

It's harder to build and grow general-purpose AI tools now. We've started to focus on a niche (researchers) and a specific use case ("summarisation").
We'll continue to innovate on pricing and UX.
The new OpenAI API updates will give us so much more to work with. Especially for our custom-build clients.

Follow me on X for comments on AI, development and SaaS: https://twitter.com/farez

I built and launched an AI SaaS: lessons, observations, and metrics.

farez — Mon, 25 Sep 2023 10:37:36 +0000

TL;DR? Chat with this article instead:
https://app.clarifypdf.com/ask/6d7fb711-23de-428a-95b0-acab7c9f0249

Just over 3 months ago I launched ClarifyPDF, an AI SaaS to “chat with your PDF”. One of about hundreds out there.

Against all conventional startup or indie-hacking wisdom, I launched without a problem to solve, without a customer segment to serve, and without even a need for it myself.

So why did I do it?

I knew that as a developer, I couldn’t ignore AI anymore. I had to up-skill.
It seemed like anyone launching an AI app is making tonnes of $$$. Yep - I had huge FOMO.

In this post, I will share this journey and some lessons and observations. Hopefully, it’ll be a useful insight for anyone thinking about starting an AI app.

For context: I’m a web developer with 20 years of commercial dev experience. 3 years ago I started indie hacking. I don’t have any practical experience with AI - just the theories I learned at uni.

Building, Launching, Results

How I came up with the idea

I started this journey by learning the basics: prompt engineering, large language models, and the OpenAI API. ClarifyPDF evolved out of the code I was writing to learn all this. It was my “school project”!

My primary goal was to learn and then to launch something. Anything. I didn’t want to overthink it.

Learning about building for AI

As I mentioned above, I didn’t have any practical AI development experience. So I had to learn.

I shared my learnings publicly on Twitter, but this was the basic sequence:

How I validated the idea

The first “validation” was actually by observation. The growth of products like ChatPDF, SiteGPT, and Typing Mind was phenomenal. At least in the short term, the demand for a “better ChatGPT” was clear.

I didn’t try to do any other validation. I was going to let my launch bring in the data.

How I built it

I didn’t want to overthink it and I knew I had to move fast. It felt like everything was (and still is) changing so quickly in this space anyway, and the only sane approach was to launch and iterate. I used what I already knew (Laravel / PHP / Tailwind).

I did wonder if I should learn Python first because most of the open-source AI code examples and libraries out there are built with Python. But that felt like procrastination and a distraction. If the app takes off I can learn Python later.

For the database, I went with PostgreSQL because it’s the closest to MySQL, which I am already familiar with. I would have preferred to use a cloud vector database to save time, and I did look into various options. But they all required more time to learn. Again, speed to market was the priority.

For payments, I strayed from what I knew (Paddle) and went with Lemon Squeezy.

Mistake.

Although it was easy to integrate Lemon Squeezy, at the time it was still a bit buggy. I lost time trying to debug it. I was going to go back to Paddle when they fixed the bugs. So I stayed. This cost me some time.

Pricing

I went with a one-time purchase model. Simply because this was easier to implement than subscriptions!

I launched with $4.99 per PDF. Which, in hindsight, is insanely expensive for what most competing products allow people to do for free! Well, I didn’t know, did I?

The price evolved after the launch. Through feedback and usage data, it evolved to $1.99 then finally to $0.99 per PDF now.

Interestingly, when I halved the price from $1.99 to $0.99, the number of purchases doubled. So halving it got me the same total revenue.

But, crucially, it got me double the number of customers, which is awesome for feedback.

How I launched it

Posted on Twitter (1,500 followers), Hacker News, and Indie Hackers.

Then it got picked up by some of the larger listing sites, the biggest source of traffic being There’s An AI For That. And they listed ClarifyPDF for free.

This is just a guess but I think it got picked up because I was building in public and, at that time, these sites wanted to grow fast so they were sucking up any AI app they can find. I was lucky to launch within the GPT hype window. Most of these listing sites are not free anymore.

Customer feedback was priority #1 at this time. From a previous SaaS, I learned that a chatbox is great for this, so I launched ClarifyPDF with a Crisp.io chatbox from day 1.

Results

First week:

Visitors: 1,000
Revenue: $45.42

First month:

Visitors: 2,800
Revenue: $115.02

To date:

Visitors: 11,600
Revenue: $320.83

Lessons

Compared to how much the “big” indie AI apps out there are making, ClarifyPDF is tiny! It didn’t make a tonne of money. But I did learn a tonne. I share some lessons and observations below.

Please note that this is based on my narrow experience of building a small, very specific type of AI SaaS - a “chat with document” GPT app. I can’t speak for all of the AI landscape!

What I Did Right

Not overthinking it.
Using what I already know.
Moving as fast as I could in this competitive space.
Focusing on learning.
Building in public.
Getting in early.
Automated follow-up emails.
Crisp chatbox.
Talking to customers.
Having analytics in from day 1.

What I Did Wrong

Treating it as a “side project”, even after seeing positive signals. I was working on this about 1 day a week. This is a fast-moving sector. It should have dropped everything and worked on this full-time to give it a chance to grow fast.
Assumed I could mimic the success of others, just by building it. Nope.
Not doing enough marketing. IMHO, to move fast in this market, your time needs to be at least 50% on marketing.
Giving in to distractions: other projects, starting new product ideas, starting to work on a course.
Didn’t offer alternative pricing models. By charging a one-time fee that’s on the ‘expensive’ end of the spectrum, I drove away customers with a need to process lots of documents. A potentially more lucrative market.
I stopped building in public. My initial efforts of building in public brought some visibility to what I was working on, and I think helped with initial traction. But after the launch, I stalled. I used “need to build fast” as an excuse to not communicate regularly about what I’m working on. This killed off the momentum from earlier efforts.

General observations - market

New innovative platforms create opportunities we can ride on. I saw this with Notion when they released templates and their API. And then with OpenAI when they released their API. Mass adoption and mass platform growth are market makers. Building and launching quickly on these platforms can really bring in a lot of early traffic. But it doesn’t last long. Catch the wave early and ride it to the beach, before it’s gone.
I was too late. Those who launched early this year saw runaway success because they were first and they caught the wave created by ChatGPT. That wave is now gone.
But I’m still early. That first wave is responsible for creating a huge amount of awareness. This has made it easier for anyone launching now to explain the benefits of AI. It’s an easier sell. Provided you are solving a real problem. And it has opened up a huge market, which indie makers can jump in now and still be early in.
It WAS about who’s first. Now, it’s about who’s better.
Students, teachers, and researchers form one early adopter group for GPT. They are the ones that have to consume and generate lots of documents on a day-to-day basis. Lots of boring manual repeated tasks. This is a market that’s craving AI tools to help them do their work faster and better.
Businesses want automation. Not just a chatbot. “Which manual process can we streamline? Who can we replace?” are questions they ask. The AI solution needs to solve these.
There is a massive non-English-speaking market. AI makes it easy now to handle documents in almost any language, so your customers will be expecting your app to do that. Anyway, there’s no excuse not to because the barrier to supporting multi-language has been lowered by AI.
I see lots of opportunities right now in 4 areas: 1) selling “picks and shovels” to other AI builders, 2) selling a focused solution to specific problems, 3) selling training, and 4) selling consulting. I think (3) and (4) are growing and easiest to get into right now for indie makers.

General observations - product

The fundamentals still matter: start by solving a real problem for a small group of people.
In the early stages, user feedback is more valuable than revenue. I halved my price and got double the number of customers. Same revenue, but more user feedback.
A chatbot is not a solution. It’s just part of the overall solution to a customer’s problem. People need to do something with the answer they get out of a chatbot. Were they lazy and didn’t like reading? Were they overwhelmed with so many documents? Do they need to create other types of content or feed it into their process?
OpenAI’s API is still the quickest engineering route to market so far. And one of the cheapest.
Use open-source projects. They’ll save you time. Most of the backend work I’ve done on ClarifyPDF can now be done in 5 lines of code with Embedchain!
Costing is tricky. LLM providers typically price by tokens used. But this is not the most convenient model for your customers. You’ll need to work out the arbitrage. But you do need to work out your costs properly as they could get out of hand.
Your pricing model picks your customers. ClarifyPDF’s one-time purchase model is fine for single documents. But drove away those with lots of documents to process. This can skew your analytics.

General observations - engineering

Building a chatbot is easy. You now have all the tools and open-source AI packages you need. Pick one, build a SaaS wrapper around it, launch early and sell like hell.
Building a good chatbot is hard. There are so many parameters. So many knobs to turn. And LLMs are black boxes. One size does not fit all - a summarising prompt is different from a data extraction prompt and is different from a content generation prompt.
Data extraction is challenging. You need to deal with this before you can even start using the data with the AI. These include extracting text from PDFs, creating embeddings, strategy for retrieving embeddings and content, database architecture, and metadata.
Prompting is an art. And you’ll never stop tweaking it. Don’t underestimate the need for good prompt engineering skills.
Summarisation is a separate problem to chat. Token limits will force you to be creative with how you summarise large amounts of text.

What’s next

The signals are good and I will continue to develop ClarifyPDF. These are our focus for the next phase:

Flexible pricing. We need to move away from one-time pricing to a model that’s friendlier to large quantities of documents. The first step is to move to credit-based pricing.
Beyond PDFs. The internet is more than just PDFs. We’re building support for all types of content sources.
Serving small businesses. We will start paying more attention to problems we can solve for small businesses. We have also started offering consulting and custom solutions, with the goal of learning more about our customers’ needs.
Expand distribution. Starting with an attractive affiliate programme. We will then experiment with a few more channels.

Hope my lessons help you in building your own indie AI app.

As always, I’ll be sharing my updates on my newsletter on building an indie AI software business. You can also follow me on Twitter and LinkedIn.

Is there a way to hide classes in Jetbrains?

farez — Wed, 13 Sep 2023 04:08:51 +0000

When editing HTML, is there a way to hide classes (or toggle it on and off) in Jetbrains editors? I'm using PHPStorm.

Sometimes I just want to see the markup and work on structure without seeing all the class names. Especially when using Tailwind where there are typically a long list of class names on a div, for example.

Installing PostgreSQL + pgvector on Debian

farez — Sun, 20 Aug 2023 09:32:37 +0000

If you're building any kind of AI app that requires storage of vectors for embeddings, and you need an open source storage solution, it's hard to go wrong with PostgreSQL + the pgvector extension.

You could go with a hosted solution, such as Supabase's vector storage. You can also host it yourself.

It's easy and I show you how to do it for the Debian OS below, which would allow you to add this to a Debian hosted website. This is also the exact setup I'm using for clarifypdf.com, a "Chat with PDF" AI app.

Prerequisities

You'll need root access to your Debian environment.

Steps

SSH into your server, with your username and server's IP address

$ ssh user@ip.add.re.ss

Install pgvector

sudo apt install postgresql-15-pgvector

$ psql -U db-username db-name

Enable pgvector

# CREATE EXTENSION vector;

Check that it's enabled

# \dx

You should see the extensions list, with pgvector in it.

That's it! You're ready to create embeddings with PostgreSQL!

Weekend challenge: Building a ChatGPT bot with Laravel

farez — Fri, 28 Jul 2023 07:50:40 +0000

Half asleep, with my brain not completely switched off, thoughts of all the new cool things announced at Laracon US last week swirled round in my head.

But being a busy startup developer/founder, finding time to play with these new toys is always a challenge. Even though I know that some of these new advances will only help me build better products.

So I thought, why not do the learning on top of what I already know! Which is why this weekend I'm going to re-build a small part of my own product with the latest and greatest from Laravel.

I'll be building a video summariser and chatbot for all of the Laracon videos.

// Detect dark theme var iframe = document.getElementById('tweet-1684714891947765760-610'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1684714891947765760&theme=dark" }

I only have a weekend. Let's see where this thing goes!

As always, I'll be building in public. If you want to follow along, follow me on Twitter for the play-by-play, or just read the summary and results in my newsletter.

Simplify your Laravel & Blade ifs: @pro, @free and @guest

farez — Tue, 30 May 2023 11:49:23 +0000

Custom if tags to clean up your Blade templates.

If you're building a SaaS, you'll eventually start accumulating a lot of if statements that display one version of content for pro users (your paying subscribers), your free uses (if you have a free tier), and your guest users (those not logged in).

You can use @if directives in your Blade templates for this, but eventually it starts getting ugly, especially if the conditions are long and complex.

    @if (auth()->user()->isProUser())
        <button>Click here</button>
    @endif

    @if (auth()->user()->isFreeUser())
        <button>Upgrade</button>
    @endif

    @guest
        <button>Sign up</button>
    @endif

It'll be better if it can look like this instead.

    @pro
        <button>Click here</button>
    @endpro

    @free
        <button>Upgrade</button>
    @endfree

    @guest
        <button>Sign up</button>
    @endguest

Well you can do that with Blade's custom if statements.

Just add the following to your AppServiceProvider's boot method:

    public function boot()
    {
        Blade::if('pro', function () {
            if (auth()->guest()) {
                return false;
            }
            return auth()->user()->isPro();
        });

        Blade::if('free', function () {
            if (auth()->guest()) {
                return false;
            }
            return auth()->user()->isOnFreeTier();
        });
    }

More on growing my indie SaaS business at https://farez.substack.com.

Building a basic "chat with a PDF" app with Laravel and OpenAI

farez — Sat, 27 May 2023 12:03:00 +0000

Earlier this month I decided to start learning how to build AI products in my free time.

It's been quite a satisfying journey. Based on what I've learned, I even wrote up a sort of cheat sheet for building chatbots. And once you've learned the new ideas and components of an AI app, it's not that hard.

The app uses OpenAI's API and I'm using their GPT-3.5-turbo model. I'm using their embeddings endpoint to create embeddings for the uploaded PDF content, and using the chat endpoint to ask the AI questions about the document.

In the requests to the API, I asked it to assume the role of "an explanation bot that explains complex information in simple everyday English".

The learning project actually turned into a half-decent app for interrogating PDFs. Even I myself was impressed with how useful a simple AI integration can be.

To test it out, I uploaded a long PDF from the UK Home Office. It's a document explaining how to apply for UK citizenship. Basically, a long and tedious document to read. Then I asked it a few questions.

I liked how it summarised the answers and explained them back to me in simple English. Actually, I'm more of a bullet-point kinda guy so I would actually have preferred shorter answers in bullets. But this still saved me a tonne of time trying to read through the document.

Once I had the basic functionality working, then I tidied the frontend up a bit with some simple Tailwind classes. Instead of the usual chat box at the bottom, I decided to put it at the top and have the AI's responses appear below it.

Here's the tech stack for this simple app:

Backend: Laravel + Nginx
Database: PostgresQL + pgvector extension
Frontend: Livewire + Tailwind
AI API: OpenAI / GPT-3.5

I go into more detail about the above in a Twitter thread.

For us indie businesses, building is just half the story. To turn this into a money-making project, I'll need to launch this and have people pay to use it.

This is my task this weekend - polish and launch this learning project as an actual product. And yes, I have bought the domain name: clarifypdf.com :)

As always I'll be sharing all the details as I go on Twitter @farez. Or you can just sign up to my newsletter and get posts like this one on my AI SaaS journey.

How to create a chatbot with OpenAI's API: a conceptual cheat sheet

farez — Fri, 19 May 2023 16:27:07 +0000

I spent the last couple of weeks diving into AI and I've been learning how to build a chatbot that uses my own content.

I've outlined the general steps for creating one, as a "cheat sheet" to myself, so I'm sharing it here.

So if you want to build a chatbot with your own content, here are the general steps you would take.

Setup

Create an OpenAI account and get your API key.
Create a vector database, e.g. PostgreSQL with pgvector or Redis.
Create a table to hold all your embeddings (OpenAI's vectors require 1536 dimensions).

Process your documents

Gather all your documents ad convert them into text. Convert line breaks and tabs to spaces (OpenAI’s recommendation).
Break the document content into chunks. Each chunk should be small-ish, e.g. 2,000 words (look up OpenAI's tokens for more specific settings).
Use OpenAI’s API to create embeddings for each chunk.
Save each chunk into the vector database.

Create a similarity search function

Use a similarity search function to retrieve the correct chunk, based on a question. OpenAI recommends the cosine similarity calculation.
Test it out and tweak the parameters.

Create your user-facing app

Create a form to ask questions and display responses.

Write your prompts

There are 3 types of prompts:

Information gathering prompt: A prompt for OpenAI to keep asking questions until it has all the information it needs.
Summarise question prompt: Another prompt to summarise the question.
Answer prompt: A prompt that combines the final form of the question along with the relevant chunk of information.

Get chatting

Host your code and database somewhere.
When someone asks a question, send the question and the Information gathering prompt to the OpenAI Chat API.
Repeat until OpenAI responds that it has enough info.
Send the chat transcript to OpenAI with the Summarise question prompt.

Answer the question

Use the OpenAI API to convert the summarised question into an embedding.
Search the vector database for the chunk that would most likely contain the answer, using the similarity search function you created earlier.
Use the Answer prompt to send the summarised question and the chunk to the OpenAI Completion API to get the answer.
Wait for OpenAI to respond and display the answer to the user.

That's generally it!

Would love your feedback, especially from those who have already been building chatbots. Especially if you have a different method or process for building it.

Thanks!

I'm sharing a lot more as I learn and build a new AI SaaS, so if you want more, you can find it on my newsletter!

My customer found a bug, but I fixed that last

farez — Mon, 31 May 2021 09:57:41 +0000

For most non-trivial applications, fixing a technical bug could take hours or days. In this case, fixing the actual bug should probably come last.

First, fix the customer's confidence, followed by the customer's experience.

Then the bug.

Fix the customer's confidence

When something breaks, the first thing that happens is doubt being cast in the customer's mind. Perhaps followed by worry and annoyance, especially if they are relying on our product to get their job done.

When doubt, worry and annoyance mix, confidence erodes. Our customers will start to question whether this poor experience is going to happen again. And of course it will - you're innovating, and innovation contains bugs.

So the first job is to fix that loss of confidence.

Reply to the customer as soon as possible, acknowledge the problem, and apologise. Take full ownership and responsibility of it, even if it's someone else's job to do the actual fix. If you've been on one of those "customer service" calls where they pass you around different departments like a hot potato, you know how annoying that experience is. Be the one single contact point for your customers.

Update the customer constantly on progress, so they know you're taking this seriously, and they feel taken care of. It is better to over-communicate than to have the customer wondering what's happening. Being informed also helps them plan for any delays or issues caused by the bug in your product. It empowers them.

Find out how this bug is impacting their experience. Is it blocking their workday? Is it causing them stress? Is it impacting their revenue? This information will allow you to fix the customer's experience, next.

Fix the customer's experience

For some products, a bug can have a real impact on the customer's day. It could prevent them from doing their work, make them look bad or cause revenue loss.

When this happens, our customer is having a really bad experience. So our job is to fix that experience.

What is the bug really preventing them from doing? And how can we help them overcome that right now? Is there a workaround that we can release quickly so they can carry on with their work, while we fix the actual bug?

Fix the bug

Once we've fixed the experience as best as we can, we can then go ahead and fix the bug. We're not going to go into the details of technical bug fixing here, but usually this involves:

Getting a bug report from the customer.
Reproducing the bug locally.
Fixing it.
Testing it.
And finally, releasing it.

Remember to keep the customer updated along the way to maintain their confidence.

Example

I'll illustrate with an actual bug from my SaaS product, a Twitter bookmarker and organiser.

One customer reported that they were seeing a "500 error" when trying to load a folder to view their bookmarked tweets.

Clearly, this error is preventing them from doing their work!

So, step 1: fix the customer's confidence. I emailed this back to them 1 minute later:

I had a look at the problem and basically, the site was crashing because for some reason, the app didn't save the content of one of the customer's bookmarked tweet, and I failed to include a check for empty content before trying to display it.

I could go ahead and fix the bug, but what they really needed is to access their bookmarks so they can get on with their work.

So step 2: fix the experience. What's the quickest thing I could do to unblock the customer's progress with work? Well, the website still contained a link to the original tweet, so for these "empty" bookmarks, I could just include an error message and a link to view the original tweet. This would be quick to do and they can continue with their work. Which is what I did.

And of course, I'm keeping the customer updated while I'm doing the fixing...

Once I have tested and released the "experience fix", I communicated it to the customer and asked them to test it. Thankfully, it worked, and that seemed to allow them to continue with their day.

The fix was released within an hour of the bug report. If I had tried to do a full technical fix of the original bug, it may have taken me a day, and not to mention the pressure I would have had to do it all quickly.

Step 3 is to fix the actual bug. But even here, there's an opportunity to keep improving the customer's experience before the full bug fix.

For the bug above, I release a second interim fix, which allowed the customer to manually re-fetch the empty bookmark's content from Twitter, should they encounter the problem again. Not a full fix, but a slight improvement to the first one.

Of course, this was communicated to the customer that reported the problem and was received positively.

Throughout this process, I was also updating the product's Twitter account so other customers are made aware of the bug.

Make the customer happy

At the end of the day, our goal is to make the customer happy.

So here's my framework for dealing with bugs reported by my customers:

Step 1: Fix the customer's confidence.

Step 2: Fix the customer's experience.

Step 3: Fix the damned bug.

Where do you store all your project/client details?

farez — Wed, 21 Apr 2021 04:31:36 +0000

As a freelancer, I work on lots of different client projects. This means lots of different server environments, workflows, tools, keys, logins, and documentation.

Over the years I've been putting all this info into various note-taking apps, filed under the client name and the project name for the client.

Sometimes this is enough, but at times this can also get messy, especially when there's information shared across different projects.

And sometimes there's information that you just forget to note down and then a year later when the client comes back to me again for some new work, I would have forgotten that info and it's a pain.

So I'm wondering if any of you folks have a good system for this.

How do you store important client and project related info that you need for your work?

Idea to sale in 2 hours

farez — Mon, 12 Apr 2021 15:52:36 +0000

On 7 April 2021, Gumroad promoted their GumroadDay. It's one day when sellers on gumroad.com get to keep 100% of sales revenue.

GumroadDay looked like a success because it got a lot of exposure on Twitter and it drove sellers to promote their product on Gumroad, usually with a one day discount.

While it looked like a great opportunity for sellers, some lamented that they didn't have anything to sell to take advantage of it.

So I wondered, would it be possible to create something to sell in an hour? That thought turned into a personal challenge.

Deciding what to sell

First step: what to sell?

I only had an hour, so I needed something I could create easily and quickly. And for customers I'm familiar with.

These came to mind:

Photos

In the last few months, I've been playing around with taking stock photos and uploading them for sale on EyeEm. I have a lot of photos and it would have been easy to pick a few, edit them, and sell them.

Problems:

I don't know the customer segment well and don't have an existing audience or channel for it.
I don't think Gumroad is known for selling stock photos.

My time

I could sell my time. I'm a freelancer after all, and I know how to sell this well.

Problems:

It's not a scalable product.
I wanted to sell something that's cheap enough, and my time isn't cheap.

Documents

I'm a freelance web developer, and over the years I've built and refined various processes and documents I use for my day-to-day.

One of the documents is a "Standard Terms and Conditions" document I include in every client contract. I could repackage this easily and it can be sold at a cheap enough price. And freelancers are constantly looking for legal document templates to reuse for their own projects.

So a "Terms and Conditions document template for freelancers" seems to be the best option, because:

There is a clear problem: creating a legally binding contract document is expensive, difficult, and boring.
There is a clear target segment: freelance web developers, like me.
There is an obvious solution: a template document that's quick to use.
Execution is easy and obvious: just take what I've been using and refining for so many years and repurpose it into a template.
There is a ready distribution channel: the small audience that I have and taking advantage of the #GumroadDay hashtag on Twitter for discovery.

Creating the product

This was easy.

All I had to do was take the document, and replace all mention of my business name with this placeholder: [[ YOUR BUSINESS NAME ]].

I assumed that potential customers for this document template would be freelancers who are less experienced. So I needed to include a simple "user guide".

In doing so, I realised that Terms and Conditions document on its own is half the solution, because there's usually another document that accompanies it: a Proposal document. So I decided to also add a simple Proposal template into the package.

Again, this is easy because I already have one I've been using for my own client projects.

The result is a package consisting of a Proposal template and a Terms and Conditions template for freelance web developers, in Google Docs format.

Total time: 1 hour.

Packaging and sales copy

Next, I had to sell it on Gumroad. And this actually took a bit of time.

First I had to write the sales copy. Next I had to include a couple of screen grabs to show what the documents look like. And finally, I needed a cover image for the product.

For the sales copy, luckily I already had a prior product on Gumroad (an eBook) which I can refer to. I just used the sale copy structure from that product and tweaked it.

For the cover image, I went on Canva and looked for some ready made templates I can use. I did find one that I like, and spent 10 minutes just changing the copy.

Promotion

Once I've created the product on Gumroad and published it, I tweeted it out with the #GumroadDay tag for visibility.

I also shared it with a handful of forums and groups I'm a part of, on Slack and Telegram.

Result

Only 7 copies sold, but, the first sale came in within 5 minutes!

I wasn't actually expecting to sell any as the challenge was mainly to see if I could create and sell in an hour.

But the beauty of creating a digital product is that you can keep selling it many times.

Lessons learnt

The whole process from idea to sale took 2 hours. I didn't quite meet the 1-hour challenge I gave myself, but 2 hours is still quick.

What I underestimated was the time required for packaging and sales. This took about an hour.

Giving myself a very tight time constraint was fantastic for focus. There was no time to waste time on "research" and there was no time for perfectionism. There was only one goal: ship.

This meant I had to work with what I had and what I knew, and this is something a lot of founders lose sight of, me included.

Using what you know and selling it to people you already have access to can save you months of time.

Riding on a trend is also a great way to get exposure. In the case of this product, it was #GumroadDay in Twitter. I could also look out for other trends in future, for example #FreelanceDay and create a promotion for it.

So, in the end, 7 sales isn't much. But I can reinvest that money into ads and more marketing to try and sell more.

To me, the main lesson is this:

Building and launching requires less time than you think.

Here's the end result: Freelance Web Dev Proposal and T&C Templates