DEV Community: Chad Burggraf

How I Build and Deliver B2B SaaS Software as a 1.5* Person Indie Developer

Chad Burggraf — Tue, 19 Apr 2022 15:04:47 +0000

This is my stack and my process. It’s not the best and there are many others, but this one is mine 😊

In January of 2021, I quit my job as the CTO of a healthcare services company to be my own boss. In April 2021 I decided to pivot from my original business idea to a B2B SaaS software product called Assetbots. While the story leading up to the pivot is interesting, I will have to save it for another time. For now, I’d like to talk about my software development process, technology stack, and deployment process.

In this post, I’ll cover:

Technology and Process Goals for Indie Founders
My Tech Stack
My Hosting Stack
How I Deploy
How Much it Costs
Takeaways and Thoughts for the Future

Technology and Process Goals for Indie Founders

The primary goal for any indie founder should be speed. Working from that perspective, every choice you make while building your business that slows you down should be evaluated based on its Return on Investment of Time (ROIT). This may seem simple and obvious, but it is important enough that it cannot be overstated.

I have made many choices that have slowed me down. In fact, building Assetbots has not been particularly fast. However, I constantly review my ROIT to make sure I’m making what I feel are the right compromises for my business. Even though speed is my primary goal right now, it is not my only one, and whether I am meeting my speed goal or not must be evaluated in context.

In addition to speed, other technology and process goals that I believe are critical for indie founders are:

Familiarity You must think about so much more than the technology of the product when building a business, so it is important to limit how much new tech you need to learn.
Simplicity You will be context switching between development, marketing, sales and administration, so your tech and your processes should be simple and understandable.
Repeatability It should be easy to do what works over and over again. Both from a process perspective (creating a proposal, keeping track of feedback, evaluating metrics) and from a development perspective (adding a feature, fixing a bug).
Price Whether you’re bootstrapping (like me) or not, price matters. Don’t spend $1,000 when you could spend $100, but don’t obsess over getting that down to $10 either.

Of course, all of these goals are nuanced, and every business is unique. However, keeping speed, familiarity, simplicity, repeatability and price in mind as I work my way toward product-market-fit has been invaluable for me and the health of Assetbots so far.

My Tech Stack

Assebots is a B2B SaaS delivered exclusively as a web application over the public internet. There are effectively an infinite number of technologies you could choose to build such a product, but here are the ones I use. From the bottom, up:

Database

All non-binary data is stored in Microsoft SQL Server. Like many of my tech stack choices, I chose SQL Server because of its combination of familiarity and simplicity (in the context of the rest of my stack and my history). While it’s not the best or cheapest tool for the job in the absolute sense, it is both the best and the cheapest for me and my business right now.

Server

On the server, Assetbots is written in C# using .NET 6. The server is a monolith application that

Talks HTTP and delivers HTML
Provides API endpoints
Handles webhooks
Talks to clients via websockets
Spins up Node.js processes
Collects and reports analytics
Runs background jobs
Talks to third-party services
And more

It’s the opposite of a microservices architecture. Moreover, it’s all developed in a single Visual Studio solution with over 100 individual projects.

This one solution produces multiple web applications, console applications and client (JavaScript) applications when built – including the marketing site and main web application. A cold build takes almost 5 minutes on my laptop (although most of that time is spent in Webpack). Despite this, it’s still a positive ROIT for one reason: most of this code existed before I pivoted to Assetbots. I got a huge head start by not having to develop (or learn!) a database layer, auth layer, permissions system, common app services, build and deployment systems, and more. And despite how slow a cold build is, I rarely have to perform one.

Client

On the client, Assetbots is written in TypeScript using React. Like the server, the client is a monorepo using Yarn workspaces and contains the code for all of the web applications produced by the Visual Studio solution, as well as some additional services like MJML email templating.

While I use a ton of third-party libraries, a lot of the client is hand-rolled. I think Next.js and create-react-app are great, but this code has been adapted across multiple projects of mine and is therefore faster for me to ship with.

A few additional details on my client stack:

I use a hand-written Webpack configuration that is modularized and shared among all my projects. It is slow, but it provides all the batteries.
I use tailwindcss with a light sprinkling of Material Design as a starting point for design and layout. I do not have a designer, so it is essential that I can make attractive, usable interfaces easily.
There is no Redux, MobX or any other state management to be found. Most state is handled at the feature level using React context.
State that is synced with the server is handled using a combination of React Query and Replicache. I’ll be doing a writeup about my Replicache architecture in a future post.
The client is pre-rendered on the server and then hydrated. The code for this is custom but not overly complicated, and allows me to achieve Next.js-level initial render performance in production:

Marketing

The marketing site is developed exactly like the main web application using the same basic architecture. The big addition is an integration with DatoCMS for content management.

As I’m sure you’ve noticed, there is a theme here. The marketing site can access and make use of all the code developed for the web application, on both the client and the server. In a vacuum, it would be faster to develop the marketing site using a tool like Next.js, but in context I was able to launch faster this way.

My Hosting Stack

Assetbots is hosted in Azure exclusively through PaaS services. I don’t use any virtual machines or containers. I maintain four subscriptions, one for each environment: development, test, quality assurance and production.

The architecture is very simple and looks like this:

cmn Common services for an entire environment (development, test, QA or production). As of writing, only a Key Vault and a Storage Account are part of this layer.
www Services for hosting the marketing site. This includes a Key Vault, Storage Account, Service Bus Namespace, Azure SQL database and an App Service.
app Services for hosting the web application. This includes a Key Vault, Storage Account, Service Bus Namespace, Azure SQL database, SignalR service and an App Service.

And that’s it. My goal with this is to strike the right balance of cost, reliability and maintenance overhead. This deployment is expensive (more on that below), but not so expensive that it changes how much runway I have. In return for the price, I get four completely isolated environments that are defined entirely in code and have proven extremely reliable so far.

How I Deploy

There are two types of deployments for Assetbots: infrastructure and code. While I use similar tools for both, they are not identical.

Deploying Infrastructure

Infrastructure (in other words, my hosting architecture) is defined entirely in code using a combination of Azure Resource Manager templates and PowerShell scripts. Terraform is the standard in the industry, but ARM templates are more than sufficient for my simple use case. Using ARM templates, I’m able to define a single file that deploys my entire architecture idempotently, in parallel.

When I need to deploy an infrastructure change (for example, I recently upgraded my Node.js version from 14.16.0 to 16.9.1), I update the relevant Template.json file, commit the change, and push to develop. Within a second or so, I can navigate to my GitHub Actions panel, choose the workflow for the environment I want to deploy to, and click Run Workflow.

All the keys required to deploy the infrastructure are stored in the repository’s Actions Secrets. However, if GitHub is down and I need to deploy urgently, I can execute the same script via PowerShell from my laptop. It’s a bit more cumbersome because I must add all of the secrets via command-line arguments, but it gets the job done.

In addition to point-and-click infrastructure deployment, I also automate deployment and teardown of the QA environment daily. This is both to save cost (so it’s only running during the day when I’m using it) and to ensure that I can “easily” spin up a new environment should Azure have a regional outage. If I were serving consumers rather than businesses, I would probably skip the QA environment altogether until my business was bigger.

Deploying Code

Code is also deployed via GitHub Actions. The process is simple:

A push to the develop branch triggers a release build and the creation of a tagged release, with deployment packages as assets. This release is marked as a pre-release.
One of the triggers of the Code – Deploy QA workflow is the creation of a new release, so the new release is automatically deployed to QA. The workflow itself invokes a series of PowerShell scripts that download the release, unpack it and deploy it using the Azure Az PowerShell module. This is successful only after a status endpoint that performs several health checks reports that everything is up and running.
Once I’ve smoke-tested the release manually by navigating around the QA environment in my browser, I merge develop into main. This triggers the Code – Deploy Prod workflow. This workflow promotes the pre-release and deploys it to production. One additional step here is to first deploy to a staging slot, verify the slot’s status endpoint, and then promote the slot to production.

I’m happy with this setup overall. It’s extremely easy to rollback a bad release (database migrations notwithstanding), because each of the workflows accept a manual trigger with the release tag name as an optional parameter. I can also use the Azure portal to swap slots with the previous deployment almost instantaneously. There is a lot of flexibility here that doesn’t require waiting for a revert commit to be built, tested and finally deployed.

The main downside is how long it takes to get the initial pre-release created in the first place: about 20 minutes. Promoting a release to production takes about 2 ½ minutes, in comparison.

How Much it Costs

I alluded to it above, but this environment is expensive, at least for the scale that I’m at and the service being delivered. I’m aware that I could run a virtual private server somewhere with Postgres and Nginx for basically $0. Even so, here are my most recent invoice numbers:

Development: $45.06 This includes $45 for my Visual Studio Professional subscription, so it’s really $0.06 in actual hosting.
Test: $0.26
QA: $62.90 This breaks down to about $5 for SQL Server and $57 for App Service instances; everything else is a rounding error.
Production: $293.00 My next invoice will be at least $60 cheaper because I’ve canceled a couple of addon services that are not necessary. Again, the bulk of the cost here is in App Service instances: about $150. Another $50 for SignalR and $35 for SQL Server.

At my scale, $400 per month matters. It is my biggest single operational expense. But it doesn’t move the needle on the length of my runway, which is all that really matters. Given that, I’m happy with the tradeoffs as they currently stand.

Takeaways and Thoughts for the Future

Assetbots is made up of some solid engineering. I’m proud of the architecture and the product that architecture enables. Even so, I might make different choices if I were presented with a clean slate to build it from. With 20/20 hindsight, I would:

Make my builds faster by forcing myself onto esbuild from the beginning, even if that makes delivering some capabilities harder (like web workers and service workers, Hot Module Replacement, and so on).
Make development faster by sharing more code between client and server – for example, running my API endpoints on a platform like deno.
Make my deployment cheaper by using multiple hosting options for multiple needs – for example Vercel for the marketing site, a container for the MVC bits, and deno for the API endpoints.

Then again, the above would be faster and cheaper, but also more complicated. It might be worth it, but who knows?

As I march forward onboarding customers and searching for product-market-fit, my main concern continues to be speed of feature delivery. For feature delivery, my main bottleneck continues to be how fast my brain can ideate and execute. Until that changes or I run out of runway, I plan to keep things largely as they are, making only incremental improvements.

Thanks for reading, and please stay in touch if you’d like to follow along as I bootstrap my business by simply building a better mousetrap.

* The other ½ person is my wife, who helps with pretty much everything while working full-time and doing more than her fair share of raising our two daughters.

How to Schedule Delayed Jobs on a Specific Queue with Hangfire

Chad Burggraf — Mon, 19 Jul 2021 21:57:00 +0000

We use Hangfire at Assetbots to manage and coordinate all our background processing and event handling. While Hangfire comes with a lot of great features out of the box, it lacks the ability to schedule delayed jobs on a specific queue. Luckily for us, Hangfire’s architecture is extremely simple and extensible, so with just a little bit of custom code we can implement this feature ourselves.

Jobs as State Machines

At its core, Hangfire treats jobs as individual state machines. There are a number of built-in states that the system ships with, along with their corresponding handlers. Each state’s handler is responsible for transitioning jobs to and from that state in storage.

For example, the EnqueuedState handler adds jobs to their corresponding queue in storage. Compare that to the ScheduledState handler, which sets a timestamp on a custom scheduled metadata key in storage that indicates when the job should be enqueued.

Job Filters as State Machine Middleware

Another core feature of Hangfire’s architecture is the chain-of-responsibility pipeline. This processing pipeline has a number of stages that can be intercepted using job filters. Each filter can operate on and change the job’s behavior at that point in the pipeline. There can be multiple filters applied, each operating independently, and each applied at different levels of granularity (e.g., at the job or method level, at the class level, or system-wide).

Using filters, you can extend Hangfire to implement things like logging each state transition or reporting unhandled errors to Bugsnag or Sentry.

Using States + Filters to Schedule Jobs on a Specific Queue

As you might imagine, there are a lot of possibilities afforded by these two simple primitives. In any case, let's use a custom job state and custom queue filter to enable us to schedule delayed jobs on the queue of our choice.

We need to accomplish two things:

Add a custom piece of metadata to the scheduled job indicating what queue we want to be enqueued onto when we transition to the EnqueuedState.
Read our custom queue metadata when transitioning from the ScheduledState to the EnqueuedState and using it to enqueue the job to the correct queue.

`ScheduledQueueState`

Hangfire ships with an un-sealed state representing delayed, scheduled jobs. And since states in Hangfire are persisted as JSON using JSON.NET, we can simply extend this class and add a custom property to it. This property will be serialized and de-serialized using the default JSON serialization infrastructure.

using System;
using Hangfire.States;
using Newtonsoft.Json;

public sealed class ScheduledQueueState : ScheduledState
{
        public ScheduledQueueState(TimeSpan enqueueIn)
                : this(DateTime.UtcNow.Add(enqueueIn), null)
        {
        }

        public ScheduledQueueState(DateTime enqueueAt)
                : this(enqueueAt, null)
        {
        }

        [JsonConstructor]
        public ScheduledQueueState(DateTime enqueueAt, string queue)
                : base(enqueueAt)
        {
                this.Queue = queue?.Trim();
        }

        public string Queue { get; }
}

This class is extremely straightforward: extend ScheduledState and add a Queue property while maintaining JSON serialization compatibility. Next, we need to take advantage of this new property when moving into the EnqueuedState.

`QueueFilter`

Our QueueFilter class will do two things:

Watch for jobs being created in either the EnqueuedState or the ScheduledQueueState and grab their Queue property to store as a custom job parameter, and
Use our custom Queue job parameter when transitioning to (or electing) the EnqueuedState.

using System;
using Hangfire.Client;
using Hangfire.States;

public sealed class QueueFilter : IClientFilter, IElectStateFilter
{
        public const string QueueParameterName = "Queue";

        public void OnCreated(CreatedContext filterContext)
        {
        }

        public void OnCreating(CreatingContext filterContext)
        {
                string queue = null;

                switch (filterContext.InitialState)
                {
                        case EnqueuedState es:
                                queue = es.Queue;
                                break;
                        case ScheduledQueueState sqs:
                                queue = sqs.Queue;
                                break;
                        default:
                                break;
                }

                if (!string.IsNullOrWhiteSpace(queue))
                {
                        filterContext.SetJobParameter(QueueFilter.QueueParameterName, queue);
                }
        }

        public void OnStateElection(ElectStateContext context)
        {
                if (context.CandidateState.Name == EnqueuedState.StateName)
                {
                        string queue = context.GetJobParameter<string>(QueueFilter.QueueParameterName)?.Trim();

                        if (string.IsNullOrWhiteSpace(queue))
                        {
                            queue = EnqueuedState.DefaultQueue;
                        }

                        context.CandidateState = new EnqueuedState(queue);
                }
        }
}

Again, this class is pretty simple. We’re using C#’s pattern matching to check if the job is being created with either of the two states we care about. If it is, we are setting a custom parameter that will travel with the job through the pipeline.

Then, when the system is transitioning the job to a new state, we check to see if the state being transitioned to is the EnqueuedState. If it is, we look for our previously set custom parameter and use it to create a new version of the EnqueuedState to transition into instead.

Putting the Pieces Together

Now that we have all the code we need in place, how do we actually wire up the filter and take advantage of our new ScheduledQueueState? First, we need to register our QueueFilter into Hangfire’s processing pipeline:

services.AddHangfire(configuration: (services, config) =>
{
        config.UseFilter(new QueueFilter());
});

Finally, we can create extension methods corresponding to the Schedule overloads that we need. For example:

public static string Schedule(
        [NotNull] this IBackgroundJobClient client, 
        [NotNull, InstantHandle] Expression<Action> methodCall, 
        TimeSpan delay,
        string queue)
{
        if (client == null)
        {
            throw new ArgumentNullException(nameof(client));
        }

        return client.Create(methodCall, new ScheduledQueueState(delay, queue));
}

The above extension will let us schedule delayed jobs that don’t return a Task and don’t take a parameter onto the scheduled queue as follows:

// Acquire a reference to IBackgroundJobClient via dependency injection.
private IBackgroundJobClient client;    

// When you want to schedule your job.
this.client.Schedule(
        () => Console.Log("Hello, world!"),
        TimeSpan.FromDays(1),
        "scheduled");

It is straightforward from here how to add any other overloads you may need.

Wrapping Up

We have been happy with Hangfire’s combination of easy setup and rich extensibility while building Assetbots. It has become an important part of our internal infrastructure as we scale our background processing needs.