Building a Software Product in 2024

There are only a few weeks left in 2023. You may or may not realize how fast these weeks will pass. Are you ready to make the most of 2024?

Are you finally ready to launch that product that has been on your mind for so long? What’s gonna be the approach? Are you just going to grab another boilerplate and deploy it on a platform like Vercel?

In case you already have a product, but it’s not where you want it to be in whatever aspect – do you have the strategy how to get rid of the accumulated tech debt from the past?

But let’s pause for a second, before I’ll finish the thought.

What do I mean by Software Product?

A software product is a digital solution designed to address specific challenges or needs in any industry. This includes various forms, such as web applications, mobile applications, or Software as a Service (SaaS). The format or business model is not that important. It typically involves an integrated system comprising a Frontend, Backend with database, Cloud infrastructure, various 3rd party services, and more … all working together to provide a cohesive user experience. In summary, a software product is a comprehensive package that effectively solves a problem through a harmonious blend of technology and design.

I’m not saying it’s a bad idea to use any Platform as a Service (PaaS) of your choice. It’s definitely a good way to ship something fast at the early stage and validate your product market fit. What I want to tell in this story is how you can build a software product that’s long term sustainable, easily scalable, and that you’ll retain the true ownership of everything that you’ll create along the way … while also getting the same level of experience (even better) as with PaaS.

I’ll show you an opinionated way of how I’m doing it, why am I doing it that way and what led me to this approach.

What Options Do You Have?

Let's explore the options:

No Code – while you can use No Code tools (like e.g. Bubble – but remember this and this), there are too many limits (and unknowns) in my opinion. It’s enough for some products, but this is not the type of software product I want to talk about.
PaaS – as I’ve already mentioned, a very common choice is a PaaS platform like Heroku (but remember this), but more probably Vercel, Fly and others. They provide a fast way from nothing to MVP, good developer experience and low cost of entry. It’s good for initial validation of your product, as you can ship it fast and it will not cost too much. But – they can change something (e.g. pricing) at any time, or their feature list may lack something (you might need later on and might not know yet) which may become a huge pain and force you to migrate somewhere else. And we can certainly agree that migrating your product with real users several months (years) down the road is gonna be a substantial (and expensive) pain. This option can also become significantly expensive as you grow. But more importantly, you do not own your Cloud Infrastructure. When you think of it, these services are just layers on top of the big Cloud providers. For a better experience. They have their advantages, but from my perspective – the disadvantages for building a bigger software product that I’ve mentioned far outweigh them. I just like to keep the ability to steer my own ship.
Cloud – the option I’d like to focus on for the rest of this article (and comparing to the previous one in certain aspects) is to choose to go directly with one of the big Cloud Providers (AWS, Azure, GCP). AWS having the highest market share among them is my preferred choice. Yeah, I know … the barrier to entry is a lot higher and you need to understand a lot of things to make right decisions. Even AWS will not provide you with “the only right way" of building anything. With Software engineers being the scarcest resource, and the situation is not going to be better anytime soon, this is obviously NOT the primary choice for many. But – what if I told you that this approach can bring you not only the full ownership of everything that you’ll create, but – with the right choices – it can be even easier to navigate and cheaper than the previous one? So let’s take a closer look what do I mean.

What are you going to build?

Note: There are many ways how you can build a software product. This is my opinionated way. Substitute any technology / language with the one of your choice, but the main principle remains the same.

You want to build a SaaS product that users can access through both Web and Mobile. You need a Frontend – Web and a Mobile apps (for Android and iOS). You need a Backend – an API so that your Web and Mobile apps can access the data. You need to give your users the ability to sign-in – Authentication; and a secure way how to separate one user’s data from others – Multitenancy support, aka Tenant isolation. You want to send Push Notifications.

You also want for you or your dev team to be as effective as possible, so – equip them with the tools that allow them to focus on what’s most important – your product features that you can sell to customers. Those features that makes your business stand out. You want them to ship features as fast as possible, not to be distracted by thinking about HOW to ship those features. It means a strong SDLC (Software Development Life Cycle) – like e.g. multiple environments (dev → stage → prod), ephemeral environments and preview apps, CI/CD, various Developer Tools, etc. For that, you need some infrastructure in the Cloud. With PaaS, you get some of it. With Cloud, you need to build most of it. But – do you?

Here are the requirements summarized:

Frontend – Web App, Mobile App,
Backend – API,
Cloud Infrastructure – Environments, CI/CD,
Developer Tools to make everything as seamless as possible.

What technologies are you going to use to make all of that happen?

Note: There are many choices and you’d probably do the best when you choose those you’re the most productive with.

For me – it would be React for Web, with Remix (great article why Remix or …). React Native for Mobile. Node.js and Typescript for the Backend. AWS CDK for Cloud Infrastructure.

As I’ve promised before – this solution can be even easier than choosing PaaS – so I don’t expect you to write anything for Cloud. How? Just hold on – I’ll tell you. You can have the same experience as with PaaS – but prevent vendor lock-in, thus keep the ownership, have the possibility to extend, customize, or completely divert into something bespoke – anytime later when time will come. That’s the flexibility I like to have.

How do you create all of that? Easily. Fast … So that you can ship your MVP, having everything on AWS and owning it, achieving fast iterations with feature development. Ideally from day one.

What’s required?

In order to achieve a PaaS-like experience within your own AWS, you need to:

streamline the creation of new cloud resources and applications – Provisioning,
make reproducible builds of resources and applications – Components & Buildpacks,
have a single point of control regardless the number of AWS accounts/regions your software product is spread across or how many other 3rd party services you’re using – Console,

What else can you think about will make everything even easier?

methodology that will provide you with best practices around code organization in your repository, ideally in a Monorepo, with a way to re-use business logic across apps, eventually packaged and published as own packages – Bootstrap,
reusable packages of common features like Authentication or Push Notifications – Modules,
an option to keep all of the 3rd party services you’re using organized on a single place, allowing you to keep control of those “scattered” resources anywhere in the Cloud – Integrations,
ability to configure everything, be it an App, a Cloud Resource, Module or Integration – on a single place and make the configuration available wherever it’s required – Configuration.

Obviously, a documentation that will allow you and your team navigate every piece of it.

I can think of even more things that will make it even easier, but this list is enough for now – and – far more that you can get from a PaaS.

Building that on your own is quite complex and time consuming task. Which is another reason why many choose the PaaS route at the beginning.

But what if I tell you that you can get all of this? Even for free.

Remember: You’re doing a Mobile App too. You know that there’s no PaaS that will provide you with a really simplified Mobile experience. This will. Just a note.

So how does it work?

The list above is intentionally organized in that order.

But first – What does it mean – Provisioning? Components? Buildpacks? Console? Modules? Integrations? All of it. Those are the parts of the software product I’m building in order to help you build your software products easier, faster – and with all the things I’ve mentioned. While keeping you the owner.

Step 1. Install Provisioning

Provisioning is a free package that can be installed in your AWS account. Once there, it will make various AWS Components and Buildpacks accessible from within your account and also – create a system that will allow you to streamline Cloud resources and applications provisioning. Simply insert a new record into the provisioning database, or update an existing one, and the respective Cloud resource or application will be automatically provisioned or updated. You can control it from your terminal or from the Console.

Note: This way, you can easily deploy your whole CI/CD; by inserting a single JSON (referring the CI/CD component) into database – and the Provisioning will take care of the rest . Voilá – CI/CD is ready. That’s what I was talking about that there’s no requirement to write your own Cloud infrastructure code. You’ll simply install the best practices, AWS Well-Architected defaults, which is more than enough when you’re just starting out. And it’s definitely more powerful, because you can easily customize it down the road.

Step 2. The Code

To build your software product, you need to bring your code. Unless you’re doing the No Code, but you won’t be reading this far in case that’s your approach – you’ll be clicking it in the UI already. Bootstrap can help here. It’s an opinionated way of structuring your Monorepo with Remix for Web, React Native for Mobile, re-usable packages for your business logic, packages ready to be deployed in order to extend your Cloud Infrastructure, and much, much more.

Step 3. Modules

The main priority when launching something new is to focus on features that makes your software product different. Something that’s unique. Why your product stands out. That’s obviously not the right way of Authenticating your users or the way you deliver Push Notifications to your users. These things are automatically expected. You should not waste time building them. So consider all of this taken care of. Just install a Module, and use the feature. And your dev team can start creating the uniqueness that differentiates your business.

Step 4. Integrations

I’m pretty organized person. What I didn’t like about various products I was working on in the past were the inconsistencies how 3rd party services were being utilized and configured for usage within the product itself. Especially for larger products. Integrations thus provide a single place where you can define each and every 3rd party service your software product uses, including the configuration required to use that service. It provides clarity. Maintains consistency. You can keep things organized even when they’re actually “scattered” across the Cloud. Think access details for AppStore Connect and Google Play Teams, Fastlane you use for Code Signing, Mobile CI/CD used to deploy your mobile app, monitoring and analytics tools, even AWS Organizations and Accounts where everything is being deployed to. Organized!

Step 5. Configuration

You have to configure your Web App – e.g. to have access to a UserPool to authenticate your users. You also have to configure your Backend – e.g. to have access to the database. Or your Mobile App – whether it’s Code Signing, Push Notifications or just Google API key to show maps. You also need to configure your Mobile CI/CD to have access to your repository holding the source code, the AppStore Connect & Google Play to upload your app. So many things … and you end up having various configurations (with sensitive items) on multiple places. It’s hard to keep up. Just imagine having a single place for all of it. And then securely using just what you need on the places you need them. That’s Configuration.

I can continue on and on. Like the Developer Tools I mentioned earlier. CLI that your devs can use to easily do the work locally. Docker Extension to replicate and debug Cloud builds. Browser Extension to easily navigate those several-times-mentioned scattered resources across the Cloud. Devices management for fully-automatic Code Signing for Mobile, and more.

On top of all of that – you own everything. It’s deployed into your own AWS account(s), the way you choose. Here I’m getting to my main point – own your creation. Do not let anyone else decide. Yes, there’s certainly a higher level of responsibility, but my opinion is – it’s well worth it when you take it seriously.

You may argue: “But what if AWS will change its prices?” While that might happen, it’s much less likely (from past evidence) than some platform (with the intentions of investors) changing that. And – in case AWS will do that, everyone reselling their services will have to do it too.

Conclusion

This is my take on how I’m creating products in 2024 and beyond. I want to have full ownership of the thing(s) I’m creating. I want to be able to steer my ship. And I want that for you too.

Doing it properly can even save you money at the beginning. Compared to the other approaches. And it’ll definitely save you money in the long run. It’ll give you more of – everything. Especially ownership.

If this resonates – I can show you, instead of just telling.

I’m creating products for a long time. I did for many companies, for more than 17 years. Continuously advancing as my skills and technologies evolved. For the past almost 2 years within my own software product that allows others create software products much more easily, keeping the ownership in their hands, preventing vendor lock-ins. It’s starting to pay off as I already have all of the above-mentioned concepts, principles and tools already in place. And you can get them too.

Let me know what do you think in the comments. I’m curious and I’ll appreciate your honest feedback.

I can help you create your (next) software product. I can give you results in a matter of days. And keep you the owner.

Are you ready to take the reins of your software product? Reach out, and let's discuss how you can build a future-proof, scalable, and truly yours software product.