My Solo Developer Stack

Building applications has changed since I have started as a web developer. We went from setting up linux servers to writing code to set up linux servers for us. What a wild time to be alive or something like that. This article goes over how I develop applications in 2025 and how the underlying fundamentals have not changed in the past 30 years. The interfaces in which we create our servers and configure them have changed immensly and for the better.

Infrastructure as Code

The Infrastructure as Code phenomenon is alive and well. As developers, we don't click around in uis (aws or self-hosted). We write code that creates servers, configures them, and deploys code to them, making software engineering a more important skill every day. I like to use Terraform and Ansible for my infrastructure. Terraform allows you to define entire networks filled with databases, servers, subnets, and firewalls in a single file. Wheras Ansible is where I write scripts that perform common tasks to maintain my servers. It is important to learn Linux before jumping into weilding a tools like Terraform and Ansible. To do anything productive in these tools, you need to understand how to do the tasks they are doing manually as you will be writing the code for those tasks. Below is a simple Terraform and Ansible example.

Terraform Example

Terraform code is storred in tf files. These files contain the code to create entire corporate networks with a single command and greatly simplify the maintainence of the network and has allowed small teams to do the work of larger teams. The terrform script below creates a server with a firewall that allows web traffic through in Linode's cloud environment.

Ansible Example

Ansible code is stored in individual yml files called playbooks. The playbook below is a simple task to perform updates on an Ubuntu server.

- name: Update Packages
  hosts: ubuntu

  tasks:
    - name: update repositories
      ansible.builtin.apt:
        

    - name: upgrade packages
      ansible.builtin.apt:
        

Software Deployment and Distribution

Software deployments have been automated at an increasingly high rate. This allows software teams to deliver software at a faster pace with more confidence in what they are producing. This process usually involves tools like continuous integration/continuous delivery or CI/CD and a server that can be deployed to in an automated manner.

Continuous Integration/Continuous Delivery

CI/CD is a pipeline that runs a lot of automated tests including unit tests, end-to-end-tests, static code analysis tools, etc. and allows developers to merge their code into the main branch if the pipeline passes. If not, the merge action should be blocked until it does pass all of the required stages.

Pipelines can also be used to block the deployment of software in the event that an error or bug has been caught by the pipeline.

Server Compatibility

Just having a pipeline does not completely automate our deployment process and in-fact, we are not attempting to automate the entire process. We still want to be the person in control of if that software is deployed into production. We want everything around it to be automated so that we make the decisions and the software does the difficult work. This is why I chose to use Docker and Docker Swarm for my server environments.

If you are already using a docker-compose.yml file to develop locally, you can deploy that same docker-compose.yml file to a server running Docker in swarm mode in a test or production environment. This greatly simplifies deploying software compared to using a tool like Kubernetes at the SMB scale and makes it more efficient too.

Frameworks

I mostly specialize in developing in React and Svelte. Although I do love static site generators (11ty in particular) to quickly spin up content based websites like blogs and documentation, Next.js as well as Sveltekit have made developing data dense and content rich websites very easy and secure when done correctly.

T3 Stack

Special shout out to Theo for creating and maintaining the T3 stack. I hadn't really been in the loop as much as I normally would be when TRPc and Drizzle came out. I had honestly been pretty burned out and didn't really want to work on anything. Once I did come back to my old self I used his T3 stack to develop a medium sized businesses website and it was fantastic. I really liked how TRPc gives me a tight coupling to the underlying data through types while providing a way to keep business logic in the server side. This combined with React Server Components made developing a rich and powerful experience feel very easy.

Next.js

I use Next.js for web applications that benefit from the features and traits of React and Typescript (due to how typesafe TRPc make the application) more than it detracts from what makes that particular application money. This makes it a great choice for applications like ecommerce websites, social media websites, and other websites that deal with a lot of dynamic content.

Sveltekit

Sveltekit is a great complimentary framework for React. Sometimes I want to make a website that is rich and dynamic but in ways that are difficult in React. A great example is content heavy websites. React makes displaying content from a CMS quite complicated due to how you display HTML that is stored in the CMS. While Svelte has first class support for this with the @supports directive. Sveltekit is also powerful enough to map JSON data from more modern headless CMS solutions to components developed locally and allows for individual components to support Typescript.

11ty

I use 11ty because it allows me to develop layouts, write my content in markdown files, and then generate a bunch of HTML and CSS files and put them on a web server like nginx. This approach has a lot of trade offs. The benefits that I wanted were simple content creation, minimal security overhead, and minimal server maintainence. What I trade off for these benefits are a more complicated deployment process that is manual at first, but can be automated over time with Ansible.

Observability Stack

We have gone over the technology I use to create infrastructure (networks, subnets, servers, etc.), develop applications (t3 stack and sveltekit), and now I want to talk about how we handle application ovservability. App observability is a fancy word for log collection and aggregation. I use Elasticsearch, Logstash, and Kibana to handle observability in all environments. This gives me a visual dashboard that I can write queries in to pull data from Logstash, which pulls your application logs in from Kibana. This is a very deep topic that I will over in greater detail in its own article.

Closing Remarks

This software stack side-by-side with good security auditing practices is what will make organizations simple and efficient.