Share

Customers Don’t Care About Your Tech Stack At All

You’ve heard it before, but I’ll say it again: Your customers and users don’t care about your tech stack.

Should you?

How much time are you spending on deciding which tech stack to use for each new project you spin up? Or looking at it from another angle, how much time are you spending forcing your current stack to do what you want it to?

With the SLAPPSHELL tech stack, I can launch for free and get up and running extremely quickly.

With SLAPPSHELL products that come from that, you get to leverage that same technology and launch pretty much instantly.

I’ll show you how.

Whether you want to use my solutions or build your own - here you’ll learn exactly what I build with and why.

This post contains no affiliate links, this is just a breakdown of what I’m using.

Will my tech stack determine whether a project is worth $0 or $1,000,000?

Some people obsess over which tech stack is the best for each new project they want to start.

And you can spend hours and hours sifting through Reddit threads, X tweets (“x-es”?), and write ups to find out why technology A is the best thing ever or the worst thing ever.

It really doesn’t matter. Every technical direction you take is going to come with pros and cons, just like anything else.

So, what should you do?

Like a lot of the things required to get your project started, the tech stack is not core to the value you’re bringing. Going with SvelteKit or NextJS is not going to be the reason a customer picks you.

Making Imperfect Decisions with Unknown Variables

When you’re starting a new project you don’t know what you don’t know.

You can try to game out all the reasons why you might want to pick one framework or database or hosting platform over another.

But, in doing so you’re probably thinking about second or third order problems that you don’t even know if you’ll encounter.

Yes, it’s smart to consider scale and technical implications so as not to shoot yourself in the foot, but you’re probably over complicating it.

My Catalyst for a Change

When I started getting into the online business space, I ran everything on Wordpress.

It was easy and I had worked with Wordpress before, and I didn’t know much programming.

It started with finding plugins and themes that could do what I wanted my projects to do.

Anything pseudo programmatic was handled via spreadsheets and manual WYSIWYG input.

That eventually evolved into some custom Javascript and CSS to extend some functionality here and there.

Now, I’m not saying Wordpress is a bad choice at all. It’s a great option for a lot of use cases.

However, for me, the drawbacks were becoming greater and greater over time.

I hosted different projects on the same server, and there were plenty of times when doing something in the dashboard of one project crashed everything.

Messing around in the host’s cPanel file manager was not the greatest development experience.

Plugin and theme licensing would add up, and I’d realize that I didn’t always like or need what I was paying for.

And at some point I was staring down the beginning of a new project that I wanted to do a bunch of programmatic content stuff with.

Remember, my typical flow was not really programmatic at all, but spreadsheet formulas and copy/pasting into the editor a million times or using WP Import/Export.

That habit was developed during my time as an SEO creating spreadsheets of keywords and meta tags and redirects by the 1,000s.

If I wanted to take my projects where I envisioned it was time for a change.

I realized I was spending too much time and money trying to force (or fix) my current tech stack to do what I wanted instead of working on the core of the project.

So, I took what hacky knowledge of Javascript, HTML, CSS, and a teeny-tiny bit of SQL and started doing some self-guided study, tutorials, and test projects to see if I could make the jump into full stack programming.

How I Picked the Tech Stack for SLAPPSHELL

I’ve built projects (failures and successes) on everything from plain HTML, CSS, and vanilla Javascript to Wordpress to, more recently, NextJS.

In fact, my first really big success was built on Wordpress with a handful of plugins and some custom javascript.

There are really only a few questions I needed to asked myself:

• What does my website/application need to be capable of?
• What am I familiar with (or can get familiar with)?
• How much do I want to spend (money & time)?

The first question doesn’t help too much because I found that you can really achieve almost anything on any tech stack you select - ignoring hacky-ness and all that.

The next two questions are far more important - especially if you work solo like me or with a small team.

What do I already know? Have I been using something for work or learning about something new? Do I like using it or have I heard good things about it?

If I don’t know something, how’s the documentation and community support for it?

You can get pretty far with a good Youtube tutorial.

Next, how much time or money do I want to spend on something?

These two things are often at either ends of the decision scale.

You’ll probably find that certain solutions are simply abstractions of something that you could do yourself for less cost. And if you have the knowledge and time, great.

For me, I like to learn and try new things, but my time to do that is far more limited than it used to be.

Nowadays, I typically find the slightly extra cost to be worth the ease-of-use and time savings.

I’ve got a toddler, I personally don’t want to be spending any time messing around in AWS.

So, I’ll break down what I’ve been using, my thinking behind it, and why it works for me.

Thinking In Systems

If you’re a solo maker or a small team, thinking in scalable systems that you can reuse is key.

That approach has allowed me to launch new ideas extremely quickly, publish content at scale, and focus more on the core of the project I’m working on.

Once you’re familiar with something, each time you use it becomes easier.

And that is exactly how I’ve approached the SLAPPSHELL project.

Since I’m building solutions for both myself and for other businesses in the form of boilerplates and managed services, the criteria I’m using are as follows:

• Easy to use and good documentation.
• Extendible for a variety of use cases.
• Scalable usage tiers that you can launch cheaply or for free.

That’s pretty much it.

Before I started SLAPPSHELL // WAVE ARCADE, my professional background was digital marketing, SEO, and information architecture.

All my programming knowledge is self-taught and all my experience is on projects of my own.

So I also wanted to build a foundation that would:

• Make it easy for myself (and people/businesses) like me to build exactly what they wanted easily with any level of programming experience.
• Check all the boxes I’d be recommending to clients in terms of SEO and IA.

I find all the solutions I’ve chosen to be easy to use, easy to reuse, and foundationally solid.

With that, let’s take a look under the SLAPPSHELL hood.

Frontend <-> Backend

As I migrated away from building Wordpress sites and ventured into the world of programming, my first stop was naturally diving deeper into Javascript as I had some hacky familiarity with it.

From there, I stumbled into React, and finally NextJS.

NextJS is a framework that I find extremely easy to set up and work with.

Coming from an SEO background, it’s built with core features that are ideal for speed and rendering.

It’s also very easy to automate all the foundational on-page SEO I used to have to convince clients to spend time fixing.

I can set things up once, and depending on how I build certain pages - I never have to think about it again.

The App router makes it simple to build out and organize the hierarchy of the frontend site.

And the nature of React components makes development feel more like Legos than anything else.

You don’t need to know much to get a decent, functioning result with NextJS. And the documentation and support makes it easy to expand your knowledge as you need to.

For SLAPPSHELL boilerplates, I’ve set them up to be fully customizable via configuration files.

If you want to launch with 0 programming knowledge at all, all you need to do is enter the options or text strings in the configs and you have a ready-to-launch, modern full stack site.

I even created interactive wizards that allow you to answer questions and get an output you can copy and paste right into your config files and variables.

API routes, data fetching, as well as server actions make it easy to build a dynamic site with logic you can follow.

UI, Themes & Design

Here’s another example of something that people spend way too much time on at the beginning: the design of the site.

I’m very guilty of this, but I’m trying to get better.

Designers are not going to like me for saying this, but on a mobile device, most websites look the same.

All that your design should be is intuitive and allow your users to find and do what they need to do easily.

For SLAPPSHELL projects I use Tailwind CSS.

Once I got the hang of it, it was way quicker for me to style on the fly as I’m building something.

For pre-built UI components, I’ll often use Shadcn/ui. They're clean, simple, and extendable.

For any animations, which I try to use sparingly and are probably for my own interest than anything else, I’ve enjoyed extending some components from the React Bits project.

Tailwind’s theme color variables make it simple to create jsx/tsx components with reusable color classes you can repurpose from project to project and only need to change a single file.

For SLAPPSHELL boilerpates, theme changes can be done with a simple, single line in the configs.

Database & Auth

For my databases and auth logic, I use Supabase, a Postgres database with a ton of extra features.

It is very easy to use - whether you want to do it from the dashboard or from the CLI.

And like all the other services I chose, you can get started for free, and scale up as needed.

The documentation and built in methods for auth checks, user setup, storage buckets, and database functions are dead simple as well.

In your codebase, you’ve got your Supabase client, server, and middleware files and you’re able to do everything you need to for auth and database interactions from there.

If you’re a visual person, the dashboard makes it really easy to see how your tables are talking to each other and drill into the different RLS policies, checks, and functions you create.

Not to mention, the Supabase team also puts out some extremely useful video updates and tutorials for different features.

Hosting & Deployment

Given my satisfaction with NextJS, I deploy and host on Vercel as well.

Here’s another area you’re going to get some push back from more experienced developers online or hear horror stories about crazy usage bills.

But, when I’m iterating and launching fast, it’s hard to beat the simplicity of Vercel.

I connect my GitHub repository, I configure my environment variables, hook up my domain, and I’ve got a super fast site that is easy to update and manage.

Again, you can launch for free and explore it with the hobby account.

If you’re worried about runaway costs (which can happen with any on-demand service), just set up a usage limit.

Once you’re receiving hundreds of thousands of visitors a month or maybe more, then it might be time to explore more cost effective hosting. Until then,I don't think it should be a major concern.

Payments

For payments, for both SLAPPSHELL and built into SLAPPSHELL products, I’m using Stripe.

Kind of a no-brainer, but Stripe checks all the boxes for easy to use, flexible, and well documented and supported.

I like it for my purposes because I can easily integrate any combination of the following:

• Custom-built OR Stripe-hosted checkout flows.
• Subscriptions OR one-time payments.
• Stripe products OR dynamic pricing (like for serviceCRM).
• Customer/payment method storage to support auto-pay and subscriptions.

For projects like SLAPPSHELL and similar ones I can easily define different types of tiers of products within Stripe, and then for business cases like serviceCRM is built for, I can use Stripe for dynamic invoicing amounts, deposits, additional charges, etc. without having to build out Stripe products.

Emails

For emails, I’ve gone with Resend.

Again, very easy to use and you can get up and running for free.

I’ve tried Mailgun, Mailchimp, and ConvertKit for other projects. The simplicity of Resend, the documentation, and development experience made it the winner for me.

I use Resend for both transactional and marketing types of emails.

Within NextJS it’s just a matter of storing your API key and verified sender domain, and then you can create server actions to trigger emails from webhooks or other events.

For serviceCRM, it was super easy to create both admin notifications and customer-facing emails for everything from new lead confirmations to final payments and recurring service subscriptions.

Analytics & Conversion Tracking

While I’m experimenting with Umami analytics for one project I’m working on in the background, I’m mostly using Google Tag Manager and Google Analytics for everything else.

Here’s why: I’m used to it and it integrates with everything you need.

I can use GTM to set up accurate conversion tracking within the apps, and then manage all my ad account and campaign conversion wiring from within GTM.

I settled on this to make it extremely easy for end users of the SLAPPSHELL boilerplates and services to track conversions accurately and plug in whatever else they need via GTM.

One of the main reasons I built serviceCRM was because of how big a pain in the ass accurate conversion tracking can sometimes be when you’re running paid campaigns.

With this setup I know I’ve got the conversion events I care about (new leads and closed leads) and I can accurately tie a dollar amount and meta data to those events.

If you’re running any paid campaigns without good conversion tracking currently, please pause them and fix that. You’ll be happy you did.

SEO

While it's not exactly tech-stack related, but I’m going to mention SEO here anyway since that used to be what I did for a living.

I’m mentioning it mostly because I’m tired of SEOs showing up on my feeds selling it as if it’s some mystical, expert level marketing strategy with all these hidden tricks.

If I hear another SEO describe Google Search Console or basic site search operators, or freaking Answer the Public as if they’re some super powerful secret thing, I don’t know man…

As a former SEO, here’s all you really need to know about it:

• Build a site that is accessible to search engine crawlers.
• Use HTTPS and ensure consistency around any root domain redirects.
• Include a robots.txt and sitemap.xml file.
• Set up a Google Search Console & Bing Webmasters account.
• Include your basic on-page meta tags - at a minimum the title and the canonical tag.
• Include any relevant schema if you want to get fancy for products, services, reviews, etc.
• Repurpose content you’ve produced for other channels and publish it on your website (and vice versa).
• Include links to your most important pages via intuitive navigation and internal links.
• Describe things how your users describe them.

Thanks, that’ll be $10,000. Here are some spreadsheets and a slide deck.

The Verdict & The Cost

While the SLAPPSHELL project is all but 2 weeks live at this point, I can share the results from a logistics standpoint.

Once I got the hang of this stack, I can now set up and launch a brand new project within the same day.

I’ve tested the flow with everything from leads businesses to SaaS projects.

That used to take me a minimum of a couple of days when I was doing everything in WordPress.

That’s also not to mention how much time I used to spend navigating between WordPress dashboards, plugins, and WYSIWYG editors.

When I was first testing the waters, I was able to get set up and running for no more than the cost of a domain, and even that’s optional.

As I got the feel for it and started adding more projects and upgrading plans, all of the above costs me about ~$80/month for hosting, database, and emails.

If you’re reading this, you’re pretty early to the party.

That’s okay though, I go to bed pretty early.

This marks just the second edition of THE SLAPPY WEEKLY, the mostly (hopefully) weekly publication in which I’ll be sharing things about the SLAPPSHELL project at large and building businesses online as just one dude.

If you like what you’ve read or there’s something more you want to hear about, let me know.

Be sure to follow along, subscribe, and join me on the social channels of your liking.

And, maybe I’ll use this old WAVE ARCADE slogan for the sign off on every one of these, maybe not… but anyway:

EXPERIENCE. EXPERIMENT. ENJOY.