Forem: Martin Dichtler

Why Most Micro SaaS Founders Fail (And How to Actually Launch)

Martin Dichtler — Sun, 01 Feb 2026 22:00:12 +0000

I think if you are in tech, at some point you have heard about building a “micro SaaS”. A single purpose software as a service application, specifically focused on solving a niche problem.
Given you are reading this right now, there is also a good chance you are following one of the popular serial founders.
I myself have been a huge fan to many for years now, building my own micro SaaS products for a bit over past 3 years. This is reflection on those years, and the hard truths that I believe any future founder should know about before they commit.

Understanding the success of serial founders

When in the world of micro SaaS we are talking about serial founders it doesn’t mean having their 3rd startup, often they are on their 10th or more that they “actively” run. One of the commonalities is their social presence. They are not simply building startups, they are evangelist for why you should build your own. They build in public, and they share their success.

Why is social presence so common among them? Their products are less about the product themselves but more about the brand of the founder. They are not selling the SaaS as much directly, rather rely on the founder and their audience to drive sales, reputation and really cross sell across other products.

The reason I quoted actively is the main thing most people don’t initially see unless they follow them for months and years, across various launches. The pattern becomes clearer and clearer with time, new product launched, founder is excited for their next new thing, older products slowly get abandoned, they are no longer their main business rather something they successfully moved away from, they are there to slowly die.

To add to products being left out to die, there is also the type of the products. They don’t simply sell software products, rather they are often starter kits, courses on building SaaS or tools specifically tailored at other current & future founders. The latter is often their biggest revenue driver, and the actual startups are means to keep you engaged.

To be clear – the above is who you see most often on social media, but there are many great serial founders, like John Rush (LinkedIn) or Rob Walling of Microconf (Youtube) who are absolutely worth your time and I highly recommend you check out.

Reality of a second job

It starts of very slowly, you initially think I’m going to put some time over the weekend into this and be done with it in no time. First week passes, you are excited about the next cool thing you are going to bring to life. Things are moving fast, you feel like you’ll be done in a month.

A month passes, you swear to yourself you are very close to launching this product. Then your brain steps in and there is new idea how to improve this, you work on the new feature, scope creep comes in, 3 months pass, no motivation left, release nowhere in sight.

This happened to me too many times to count, my github is a graveyard of abandoned projects that started as niche, and grew into fully blown SaaS that companies with 100 people wouldn’t dare to take on.

This is also the biggest mistake you will likely make as someone stepping into the world of micro SaaS. Instead of focusing on your niche market, letting the builder and inventor inside of you take over and create a vision of a perfect product.

As your scope increases, you will continue to be demotivated, it slowly becomes a second unpaid job you absolutely hate, but what do you do? You came too far to just give up now. You keep on going for few more weeks, put additional several hundred hours into it, but in the end it will not be the perfect you envisioned and you’ll never be satisfied.

If you are like me and also have a full time tech job this will slowly start taking a toll on you, 18 hour long days of coding and building products, keeping your brain engaged, you become less effective, your health will suffer so will your product.

How to actually launch

I will not just complain about how hard it is, here is the mental models I’ve learned and abilities I’ve gained through experience, that I hope you can learn from me. Let’s build a mental toolkit to help you succeed.

Reducing scope:

This is your primary tool that will take you the farthest. Think of your idea:

what is the core of the product?
what is the value?
what is the absolute minimum you have to build for someone to use your product?

What you don’t need for launch:

payments – make it free, you will not be an overnight success, gain insights – that’s your payment
automated email campaigns
perfect customizable dashboards
award winning UI & UX

Let’s look at an idea together: image optimization API (resizing, compression)

Most would think to themselves that they need:

customer dashboard / API key generation functionality
way to bill customers for their usage
usage tracking & customer analytics
customization on compression ratio, output formats etc.
workspaces to allow businesses to have multiple people manage API keys
whatever great feature you can think of!

Using the tool in your new toolkit:

What is the core of the product? image optimization
What is the value? reduce image size / resize
Minimum for someone to use it? API

Okay, cool! Now instead of complicated SaaS platform, you are building a simple API you can launch on RapidAPI.com! Existing marketplace with potential customers. You ditch the customization, provide opinionated API that always uses WebP as target format, static compression rate based on best practices and allows user to enter new dimensions, that’s it!

How long will it take you? Probably a week or two max and you are live!

This is not the end of your journey, rather the beginning, but your product is already live, congratulations! Now what’s next?

Build value:

You didn’t spend the time before launch to build fancy infrastructure around your product, rather you chose established platform to launch quickly and gain your first (even if unpaid) customers. What’s next for you?

If you don’t already have users. It’s time to roll up your sleeves and do the thing every engineer hates which is sales. You don’t have to go and cold call people hoping to find someone who can use your service, instead write value added content. Explain why you built the tool, how it differs from others, don’t try to sell them, provide value.

It will take months for your content to get engagement, stay consistent, keep creating more and more, realistically you are looking at 6-12 months of lot of effort, for not many users if you don’t immediately hit great market that’s in desperate need of your product. This is okay! Expect it and baseline your expectations on this, it’s not a failure, it’s a step towards success.

While you are searching for your first users, look at Reddit, look at X.com and figure out what people don’t like about existing solutions, join discussions and hear them out – this is your unique edge, large company will survey their users and apply feedback to accommodate most of them, but you are building a “micro” product, what do the niche users say that don’t have voice with large companies?

Continue looking for feedback even if it’s not directly on your product and iterate. Extend your simple service (maybe on someone else’s platform), create more content, gain engagement, gain more users.

Refine experience:

One of the key points I would make here is to focus on your users. While initially you provide the value of the service, as you gain users you will need to retain them. Best way to do that is to hear them out, find every single issue they might have with your service (especially technical) and fix it. There is no better killer to your software business than building something overly complex your users can’t understand or something that doesn’t work as expected, has low uptime, doesn’t work smoothly in general.

Dogfood your own product. When you created the idea it was something you’ve seen as necessity, make sure you are your own user ideally across as many surfaces as possible and look for the daily annoyances, however small they might be and make sure other users will not experience them.

Cashing in:

In our example we used RapidAPI, they handle API keys for you and monetization. Maybe this is the end for you, and that would be perfectly fine. Ending here gives you back time, you iterate strictly on the API level while the platform takes care of the rest. With your free audience you have proven that the product has market that needs it, it’s time to enable monetization and start selling access.

If you’d like to take your product beyond a side hustle, you might want to consider building your own platform, do know that this will take a significant investment. Even if you build all of it by yourself you are not simply committing the time to build it but maintenance for the rest of the life cycle of the product. That being said this comes with some perks. While you are now putting significantly more time in, you are also improving your margins by ditching possible platform fees where you hosted your product, you are keeping your user base strictly to yourself (adding future cross sell opportunity) giving you an edge with how you market to your users and building a future proof product.

If you’ve reach the point of launching your own platform here is the thing, either the product makes enough to become your full time job, or you should hire help. If it’s not making enough, you will be sad to lose the money, but what you are holding as the founder is not the profit, but rather the equity and especially if you are bootstrapped (which pretty much all micro SaaS are) this is your financial win.

Additional tips:

If you made it this far, congratulations on launching your new product! While it might seem enticing when you see the growth to keep pushing and go all in, please make sure to consider following that I didn’t include in detail to make this slightly shorter (if you want to hear more about any just write a comment & follow for follow ups!) :

rest days, if you take a vacation actually vacation, don’t simply do your second job
set time commitment limits for your business, don’t let it get out of hand
find hobby if you don’t already have one that has nothing to do with software! (can’t stress this enough)
actually spend time outside, and take care of your health (both mental and physical)
if you fail, take several weeks of break – don’t simply start with the next thing, nobody will steal your idea
your idea doesn’t have to be unique, you just have to execute well on it
focus on your users and their experience – this will take you really far
don’t get too attached, you never know what comes next (see below)

My recent launch

Very recently (mid December 2025) I’ve launched my latest product deadend.ai – it’s still in it’s very early days but without the lessons mentioned above I don’t think I would have ever managed to launch it. There is 3 of us currently maintaining it, and due to my recent full time job change, I’ll have to stop my involvement with the product – that being said I’ll follow this up with more details from my journey, the transition, more technical content on the architecture of the service and overall how we’ve been approaching the launch, if you are launching a product yourself and struggling, or simply want to get some feedback, leave a comment below the post, or feel free to reach out to me on LinkedIn or X.com and I’ll be glad to give you my 2 cents 🙂

Disclaimer: This article is based on my personal experiences and research. The opinions expressed here are solely my own and do not represent those of my employer, or its affiliates.

Cursor — My Year in Code 2025

Martin Dichtler — Tue, 23 Dec 2025 01:30:15 +0000

It’s been over a year I’ve been using Cursor after switching from Github Copilot which at the pre-GPT time did feel absolutely amazing. Let’s reflect back on the past year, the heavy conversations we as developers were having with our colleagues and with ourselves, and what next year can bring.

1.2B tokens later

I’m thinking should I be amazed? Is it a good thing? Is this a bit scary? Probably yes to all.

One thing that this year has been is full of emotions for me as software engineer. Thinking how LLMs are getting amazing with release of Claude 3.5 which to me was the very first model where I could be more hands off keyboard and get something semi decent delivered, to seeing Composer come to life, and Claude 4.5 later this year which both at it’s core seem to be capable of replacing many junior engineers.

We’ve seen many executives embrace AI with open arms, we’ve seen many engineers reject it. And if you are like me with a job in tech, or in one of the affected industries, I bet you lived through this yourself, both the excitement and fear, and I’m almost certain you have your own very opinion that you might even be afraid to share.

3.3k messages & over 600 chats

How does it feel a year later? As the models are getting significantly better, did your fear increase? Do you feel empowered? Are you concerned for the future of vibe coded web?

Myself, I was mainly concerned, especially when you hear as a developer things like “lovable” or “our PM just built this tool for us” – while this is partly a satire, it’s things you hear in reality, and they are partly about empowerment. Giving tools to less technical people that can help them better shape products, with hands on iteration is amazing idea. I remember from my project management job, learning PowerShell scripting, and Python to build tiny automations within my means (extremely restricted computer without install permissions) – was it fun? Hell yea! Was it effective? Yes, at the time.

One thing I remember however, the moment I was able to empower other people with technology that’s exactly what I pushed for heavily. “Here is this new cool tool that’s low code / no code – come learn it, I’ll show you around” – this was on my weekly schedule, I always wanted to push people into new technology because I knew, once adopted it will make them do better as individuals, it will help the company.

148 Sundays?

So what actually is the scary part with AI? Why do so many of developers reject it? Why do we resent the idea of non technical people using it?

It’s really the lack of guardrails in my opinion. I remember one of the first business tools that I loved – it was quickbase. It gave people option to move away from spreadsheets, build automation using Pipelines that ran on schedule, build interactive dashboards, all in one place – yet it kept them safe within their own sandbox.

If you look back at 2020 / 2021 we did see this with DeFi, something new, fresh and exciting. Brand new technology to many, with large adoption, however very quickly also became a significant security concerns, people weren’t used to, and many never got used to the security implications of crypto investing on decentralized exchanges, and many lost significant amounts of money to obvious scams.

This is how I see it with AI today, the introduction of new technology so quickly, while just like DeFi opened up previously unseen opportunities for many, in similar way it failed to prepare the audience to “stay safe with AI”.

I don’t believe after seeing this play out for over a year many developers are concerned for their jobs from the perspective of everyone being able to build great software, I feel like their fear comes from the lack of knowledge of people around them.

8 PM

So what do we do?
Let’s not become the nay-sayers. Let’s keep sharing our passion for technology and let’s embrace AI, but let’s do it with guardrails.

The developer community if I could highlight one thing I absolutely love is how we manage to make learning accessible, let’s keep doing it with AI. While prompting for me feels like is hard to teach and rather is acquired through experience, let’s work on content that promotes online security for non-developers building applications. Let’s educate on basics of software engineering, UX, system design, deployment and many other challenges where you know better.

Let’s focus on the problems of AI era and solve new problems that come with it – Google’s SynthID for authenticity verification, deadend.ai for hallucinated links and whatever you come up with next!

Use AI yourself to augment your workflows, use it to build software that will change the world. All those crazy ideas you had in the past you couldn’t find enough time to build? Your time just got much cheaper. Want to learn something new? Google’s Gemini got your back as your personal teaching assistant. You suck at web design? Your friendly model can do it for you.

None of this replaces actual experts in the industry, but gives you hell of a chance to make something that makes a difference for many people, and that’s what software is about to me.

Note: This isn’t AI rant, or bullish article on AI, just honest reflection of how this year I was feeling about AI from being scared to embracing it and augmenting my own work, launching my own startup – these are also purely my opinions and mine alone and don’t reflect opinions of my employers.

(and yes, the thumbnail is purposely AI generated!)

Stack | Data Structures with Go

Martin Dichtler — Sun, 21 Dec 2025 17:58:17 +0000

Stack is one of the most basic data structures that are not native to Go. Being most basic, it’s by far the easiest to implement however it will also introduce fundamental concepts that will help you down the road with other data structures so it is critical that you make sure to get really solid understanding of it as much as other concepts that will be discussed as part of this post.

What is stack and why is it useful?

Think of a stack as a stack of coins inside a tube, you can see whats at the top, if you want to add a new coin you always put it at the top, when you want to remove coins, you always take them from the top and only way to see the bottom coin is to go through the entire stack top to bottom first – this is called LIFO principle (Last In, First Out). One of the most common ways you interact with a stack in daily life is any (basic) implementation of in memory history, whether its your browser tracking previously visited pages to provide option for navigating to previous pages, or your computer directly with clipboard functionality / text editors etc*. – in a case of browser history, whenever you navigate to a new page we use Push to add new item to the top of the stack (current page / head ) and if you navigate back we can Pop the top item.

Browser history implements two stack model, backwards stack and forward stack where if you navigate back item is popped from backwards stack and pushed to forward stack – just like other examples this is the simplest way to explain without adding too much complexity

Underlying data structure of a stack

From the native data structures to Go two might immediately come to mind that are Slice and Array – before we can decide which one to use we have to get a good understanding of how they work under the hood.

Array: utilizes pre-allocated block of continuous memory, cannot grow past fixed size
Slice: just like Array it utilizes pre-allocated block of continuous memory, but unlike array when capacity is reached, new array is created in memory with double the capacity, all items are copied and previous array is de-referenced leaving garbage collector to clean it up as no references to the original array remain. However as the underlying array grows, and you start removing elements from the stack, the new larger array will maintain it’s memory allocation even if the amount of items in the stack / array has decreased and the memory is not cleaned up until the array is completely de-referenced.

Based on the two definitions above, we can do one better by utilizing variation of a linked list. It can either be singly or doubly linked list. Their structure is almost identical, both referencing Head , Value and Previous (pointer to previous node), however doubly linked list also adds Tail , and Next (pointer to next node).

Per the earlier definition of a stack, only way we traverse is is down, hence not needing Next value, and since we only read the top most item we only care for the Head, hence picking singly linked list in our case would be ideal.

What does it look like in memory using singly linked list?

When first node (value) is created it’s allocated randomly on the heap and variable Head is set to it’s pointer, whenever new node is pushed to the stack, Head is set to the new node, while new node references pointer to Previous node which ensures garbage collector will not clear the memory where it resides. Finally when an item is removed from the top of the stack, Previous becomes the new Head , removing pointer reference to the old Head , hence garbage collector will find orphaned block of memory and clean it up.

Take a note that implementation in Go can be drastically different to implementation in other languages, the performance considerations you’ll get from implementation in Go might not be universally true in other languages such as JavaScript and neither will be the underlying structure definitions due to different behaviors depending on their language level implementation

Develop tests

Let’s start building our first stack (well, tests actually)! We are going to utilize Go’s “testing” library to write basic unit tests to validate our functionality even before we start implementing the stack to create a safety net.

package stack_todo

import (

    "testing"
)

func TestPushToStack(t *testing.T) {
    // initiate new stack of your preferred data type
    stack := NewStack[int8]()

    // push an item to ensure stack is not empty
    stack.Push(2)

    // peek to find last item
    got, err := stack.Peek()
    if err != nil {
        t.Errorf("Peek threw an unexpected error: %q", err)
    }
    want := 2
    if got != int8(want) {
        t.Errorf("Push failed: received %d, expected %d", got, want)
    }
}

func TestPop(t *testing.T) {
    stack := NewStack[int8]()

    stack.Push(3)
    stack.Push(5)
    // this element will be popped
    stack.Push(1)
    stack.Pop()

    got, err := stack.Peek()
    if err != nil {
        t.Errorf("Peek threw an unexpected error: %q", err)
    }
    want := 5
    if got != int8(want) {
        t.Errorf("Pop failed: received %d, expected %d", got, want)
    }
}

func TestPopEmpty(t *testing.T) {
    stack := NewStack[int8]()

    stack.Pop()
    // test the size is handled correctly
    got := stack.Size()
    want := 0

    if got != int32(want) {
        t.Errorf("Pop on empty failed: received size %d, expected size %d", got, want)
    }
}

func TestPeekEmpty(t *testing.T) {
    stack := NewStack[int8]()

    _, err := stack.Peek()
    if err == nil {
        t.Errorf("Failed to throw error when peeking an empty stack.")
    }

}

func TestSize(t *testing.T) {
    stack := NewStack[int8]()

    stack.Push(1)
    stack.Push(2)
    stack.Push(4)
    stack.Push(2)
    poppedValue, err := stack.Pop()
    if err != nil {
        t.Errorf("Pop threw unexpected error: %q", err)
    }
    if poppedValue != 2 {
        t.Errorf("Pop returned incorrect value: %q", poppedValue)
    }
    stack.Push(6)
    stack.Push(3)
    poppedValue, err = stack.Pop()
    if err != nil {
        t.Errorf("Pop threw unexpected error: %q", err)
    }
    if poppedValue != 3 {
        t.Errorf("Pop returned incorrect value: %q", poppedValue)
    }

    got := stack.Size()
    want := 4

    // have to use int32 as the size is defined stack level
    if got != int32(want) {
        t.Errorf("Size validation failed: received %d, expected %d", got, want)
    }
}

The most important parts to understand here is when writing tests, make sure you consider your edge cases, specifically functions TestPeekEmpty and TestPopEmpty are the edge cases for us with stack, if stack has no nodes, we are unable to Peek as the head is not set, we wouldn’t be able to reference Value of the head. Pop is similar story, for two reasons, our Size of the stack is set to int32, hence we cannot use negative numbers, we have to ensure that when attempt is made to pop an element of an empty stack, size is not being decremented. We also established that Pop is looking at Previous of our stack to set the new Head but if Head is nil the application will panic to nil pointer dereference.

Now that you know how to test your stack, feel free to pull the example repository and try to implement stack yourself, if you get stuck run tests to figure out what is still missing or reference the examples folder.

Try implementing stack yourself: https://github.com/mdichtler/Go-DSA-behindthe.dev/blob/main/internal/todo/stack/stack_todo.go

Run tests to validate your implementation: go test ./internal/todo/stack

Implementing stack

Let’s create a new file stack.go and create some boilerplate, start by defining the node shape, interface with list of all of our functions, stack struct and init function.

package stack_todo

type Node[T any] struct {
    Value T
    Previous *Node[T]
}

type Stack[T any] interface {
    Peek() (T, error)
    Push(value T)
    Pop() (T, error)
    Size() int32
}

type NodeStack[T any] struct {
    Head *Node[T]
    size int32
}

func (s *NodeStack[T]) Peek() (T, error) {

}

func (s *NodeStack[T]) Push(value T) {

}

func (s *NodeStack[T]) Pop() (T, error) {

}

func (s *NodeStack[T]) Size() int32 {

}

func NewStack[T any]() Stack[T] {

}

Peek & Size

By far the easiest two functions of a stack are Peek and Size – for implementation of Peek let’s remember back to our original example of a stack of coins where you can only see the top coin, or no coin if there are no stacked coins:

func (s *NodeStack[T]) Peek() (T, error) {
    // if Head is not set (no items in the stack)
    // ensure case is properly handled, refer to TestPeekEmpty for success criteria
    if s.Head == nil {
        var zero T
        return zero, fmt.Errorf("head is not set")
    }
    return s.Head.Value, nil
}

Implementing Size is that much easier, since we want to have as low time complexity as possible best we can do is use a variable that we created with our NodeStack struct which is size with o(1) time complexity for reading / writing.

func (s *NodeStack[T]) Size() int32 {
    return s.size
}

Push & POP

We only have two more functions to implement, let’s start with simpler one which is Push – all we need to do is:

Increment size
Define a new Node referencing current Head as it’s Previous
Set Head to our new Node

func (s *NodeStack[T]) Push(value T) {

    s.size++;

    s.Head = &Node[T]{
        Value: value,
        Previous: s.Head,
    }
}

Truly the only place you might make a mistake is implementation of Pop – to satisfy our tests, first we have to check there is at least one element in our Stack, if there is let’s handle removal:

Validate Head is not nil, if nil return an error
Decrement size
Take note of current head so we can return value that is being popped
Set Head to the Previous value of current Head
Return value of popped Head

func (s *NodeStack[T]) Pop() (T, error) {
    if s.Head == nil {
        var zero T
        return zero, fmt.Errorf("you cannot pop from an empty stack")
    }

    s.size--;
    previous := s.Head
    s.Head = s.Head.Previous
    return previous.Value, nil

}

Fully implemented stack: https://github.com/mdichtler/Go-DSA-behindthe.dev/blob/main/internal/examples/stack/stack.go

Enjoying this content?

Follow me on Medium.com and dev.to

Queue | Data Structures with Go

Martin Dichtler — Sat, 20 Dec 2025 22:07:42 +0000

LIFO to FIFO

In the first post of the series we introduced Stack as our first data structure which follows the LIFO principle (last in first out). Similar to stack is our next data structure Queue, that follows FIFO (first in first out).

In the previous analogy we talked about a stack of coins, where new coins get added to the top and they have to be removed from the top for us to reach the bottom.

Queue as the name suggests works exactly like a queue at a DMV, you take a number, the earlier you are the lower number you have, and new numbers are called in order, essentially first come, first served.

While Stack is useful for linear history, queues in real-world engineering are useful for job queues, but also in DSA specifically will become the backbone for building one of the most common search algorithms (BFS – breadth first search).

Slice vs Linked List as underlying data structure

For the most part, when you interview for SWE jobs you will be implementing Queue as a slice, and often enough this is going to be how you solve leetcode style problems involving queue. This is very fast way to show your understanding of the concept, while not spending too much time creating boilerplate.

The danger comes from not understanding how the slice will behave in memory. Slices have length, but they also have capacity, when you initiate an empty slice, you can pre-allocate capacity, this is done by the third parameter of make.

Slice capacity also increases as you push more elements to it, whenever the capacity changes, new underlying array has to be created. In practice this means copying the data into new larger array, and garbage collector needing to clean the previous one.

The important part to remember here is that the re-allocation happens when the slice grows, not when it shrinks. So your slice will continue to take as much memory, as it took in it’s largest size.

In Go slice grows by allocating underlying array twice it’s own capacity so for each item pushed we don’t need to find new space on the heap to move the entire slice. This however means at large amount of data, for example 1M records, when you push one more record to it we hit 2M capacity even if there is only 1,000,001 records. Once you drop all of them from the slice, the underlying array remains at the 2M capacity, until it’s eventually completely dereferenced and GC can clean it up. If your variable is global, or never dereferenced this is a memory leak.

// Naive implementation
func main() {
  // init empty slice, 0 bytes
  q := make([]rune, 0, 0)

  // Enqueue:
  // capacity growth 0->1, 4 bytes
  q = append(q, '1')
  // capacity growth 1->2, 8 bytes
  q = append(q, '2')
  // capacity growth 2->4, 16 bytes
  q = append(q, '3')

  // Pop:
  // Len 1
  q = q[1:]
  // Len 1
  q = q[1:]
  // Len 0, but capacity remains at 4 and still takes 16 bytes!!
  q = q[1:]
}

We solve for this problem using linked lists, that do not create underlying arrays, and when a node is detached, the capacity is claimed back almost immediately by the garbage collector.

Nomenclature & flow

There are several important keywords to remember when talking about Queues:

Head : front of the line
Tail : back of the line
Enqueue: add to the back of the line (Tail)
Dequeue: remove from the front of the line (Head)

Before we move on to implementation the final part you have to understand is what happens at each operation. Imagine line of people standing in a queue at a supermarket, there is two flags, a green one indicating who goes first (Head), and a red one for the last person in the queue (Tail).

When a new person joins the queue (Enqueue), the person currently holding the red flag gives it to the person who just joined, as they became the new last person of that queue (Tail). When a person checks out from the front of the queue (Dequeue), they hand the green flag to the person standing right behind them moving the front of the queue (Head).

One thing you might have noticed, none of the people did care who is ahead of them, they only care who is behind them which tells us the queue will only care for a single direction, and we can use singly linked list.

Another way to imagine this is our queue looks like A (Head) -> B -> C -> D (Tail). When new person joins (E) they get the “tail” flag from D, new queue looks like: A (Head) -> B -> C -> D -> E (Tail). When A checks out, they hand their “head” flag over to B, and new queue looks like B (Head) -> C -> D -> E (Tail).

Developing Tests (TDD)

As we defined how queues work let’s think about what’s important to maintain. First one is order, at no point we can insert new items in the middle of the queue, when we add new item we should expect it to show up at the end.

Second is the size, the queue size can never be negative, at minimum has 0 elements. What happens when we try to remove element from already an empty queue? We throw an error as this is an impossible case!

Finally, for the sake of knowing who is first, we need to be able to look at the front of the queue (Peek), what happens when the queue is completely empty? One would be inclined to using nil however the proper choice here is also throwing an error. This is mostly because your implementation will often include generic type T, where nil isn’t a valid choice for all types, rather we handle the return by returning both error, and the zero value of given type.

Zero values are different per type, for bool it is False, for int it is 0, for string it is “” you can try using them in A Tour of Go: https://go.dev/tour/basics/12

// queue_test.go
package queue

import (
    "testing"
)

func TestPeekEmpty(t *testing.T) {
    // should return an error
    queue := NewQueue[int8]()
    got, err := queue.Peek()
    if err == nil {
        t.Errorf("Empty queue Peek didn't return an error, got: %d", got)
    }
}

func TestDequeueEmpty(t *testing.T) {
    queue := NewQueue[int8]()
    got, err := queue.Dequeue()
    if err == nil {
        t.Errorf("Empty queue Deque didn't return an error, got: %d", got)
    }
}

func TestEnqueue(t *testing.T) {
    // initiate empty queue
    queue := NewQueue[int8]()
    queue.Enqueue(2)
    // test case
    got, err:= queue.Peek()
    if err != nil {
        t.Errorf("Failed to peek: %v", err)
    }
    // expected value
    want := 2

    if got != int8(want) {
        t.Errorf("Failed to enqueue, expected: %d, got: %d", want, got)
    }
} 

func TestDequeue(t *testing.T) {
    queue := NewQueue[int8]()
    queue.Enqueue(5)
    queue.Enqueue(3)
    got, err := queue.Dequeue()
    if err != nil {
        t.Errorf("Failed to dequeue, error: %v", err)
    }

    want := 5
    if got != int8(want) {
        t.Errorf("Failed to dequeue, expected: %d, got: %d", want, got)
    }

    // lets also validate correctly that 3 is now at the front
    got, err = queue.Peek()
    want = 3
    if got != int8(want) {
        t.Errorf("Peek returned wrong value after dequeue, expected: %d, received: %d", want, got)
    }
}

func TestSize(t *testing.T) {
    queue := NewQueue[int8]()
    got := queue.Size()

    want := 0
    if got != int32(want) {
        t.Errorf("Size of an empty queue must be zero, received: %d", got)
    } 

    // lets add items
    queue.Enqueue(2)
    queue.Enqueue(4)
    queue.Enqueue(5)
    queue.Enqueue(2)

    got = queue.Size()

    want = 4

    if got != int32(want) {
        t.Errorf("Size not matching after enqueue, received: %d, expected: %d", got, want)
    }

    _, err := queue.Dequeue()
    if err != nil {
        t.Errorf("Failed to dequeue when testing size: %v, expected 3 more elements after dequeue", err)
    }
    _, err = queue.Dequeue()
    if err != nil {
        t.Errorf("Failed to dequeue when testing size: %v, expected 2 more elements after dequeue", err)
    }
    got = queue.Size()
    want = 2 
    if got != int32(want) {
        t.Errorf("Size not matching after dequeue, received: %d, expected: %d", got, want)
    }
}

Implementing Queue

First, let’s setup our boilerplate, we need to define the Node of the linked list. As discussed because we only care for a single direction we can only point to the next node. We also need to define Queuer, the interface holding our methods, the Queue struct itself, that includes Head, Tail, and keeps track of its size, and finally the constructor NewQueue.

package queue

import "fmt"

type Node[T any] struct {
    Value T
    next *Node[T]
}

type Queuer[T any] interface {
    Enqueue(T)
    Dequeue() (T, error)
    Size() int32
    Peek() (T, error)
}

type Queue[T any] struct {
    head *Node[T]
    tail *Node[T]
    size int32
}

func NewQueue[T any]() Queuer[T]{
    return &amp;Queue[T]{
        head: nil,
        tail: nil,
        size: 0,
    }
}

After our initial boilerplate, let’s work on adding first method that is Enqueue. Since Enqueue cannot fail* we are safe to increment the size of our queue immediately.

There is possibility of a failure if we run out of memory, but in terms of the logic itself, we never expect it to fail.

We then need to create a new Node for our new item which will give us memory pointer. We check if our queue isn’t empty, if it is we simply set both head & tail to our node and can early return. If there are items we point the current tail’s next to the new node, and subsequently set the tail pointer to the new node, this ensures it remains linked to the rest of the queue.

func (qs *Queue[T]) Enqueue(val T) {

    qs.size++;
    node := &Node[T]{Value: val}
    // if head doesn't exist, assume no tail either
    if qs.head == nil {
        qs.tail = node
        qs.head = node
        return
    }

    // add to the tail
    // set pointer of current tail to our node
    qs.tail.next = node

    // set new tail of the current node
    qs.tail = node

}

In order to handle Dequeue, we have to think about edge cases we defined during our tests, one of which is what happens when we call dequeue on an empty queue? We need to both return an error, and a zero value for the generic type.

If the queue isn’t empty, we simply decrement the size, we take a reference to the current head so we can extract its value before we overwrite the Head pointer. We then move our head forward, handing over the imaginary green flag to the next person in line.

Before we can return the value we just dequeued, we have to check if there was another person in the line, since we are dealing with pointers we can simply check if the new head is not nil. If it is we have to make sure we also update our tail.

Finally, we can return the value of the dequeued item. We return the value itself to avoid possibly modifying or accessing the .next of the value we removed, and also to ensure it gets cleaned up by GC.

func (qs *Queue[T]) Dequeue() (T, error) {
    if qs.head == nil {
        // queue is empty
        var zero T
        return zero, fmt.Errorf("Queue is empty")
    }

    // decrement size only after validating queue is not empty
    qs.size--
    curr := qs.head
    qs.head = qs.head.next

    if qs.head == nil {
        qs.tail = nil
    }

    return curr.Value, nil

}

To finish off our implementation we have Peek & Size. Since we are tracking size in a variable to avoid traversing our linked list whenever we want to know the value, we can simply return the current value of size.

We also identified that Peek can fail, so let’s make sure to care for that condition by returning an error and a zero value for given type, in all other cases let’s simply return the value.

func (qs *Queue[T]) Size() int32 {
    return qs.size
}

func (qs *Queue[T]) Peek() (T, error) {
    if qs.head == nil {
        var zero T
        return zero, fmt.Errorf("Queue is empty")
    }
    return qs.head.Value, nil
}

Summary

Both Stack & Queue and the bread and butter of DSA, as we dive deeper with the series you will continue to use them in more complicated algorithms, it is important that you understand them well and I strongly recommend putting in time to practice them as much as you can.

If you are specifically learning DSA for upcoming interviews, you can test your skills with Leetcode 75 / Leetcode Interview 150 – that personally have significantly helped me to crack Google interviews and cover this extensively.