The tech stack of your web app doesn’t matter

We’ve put together a bunch of tips on what to focus on instead of your tech stack.

1) Data is critical; everything else is workable.

It’s no secret that data governs all software, whether you are processing it, crunching it, or transferring it. Where and how you store your data plays the biggest role in your scalability and maintainability.

1.1) Data loss can kill your business

There’s a bug in the app that doesn’t allow customers to proceed with an order? No sweat; it’s fixed in no time.

The server’s down, and customers can’t reach your site? Stakeholders may react and call it a crisis, but that can also be easily fixed.

Lost a day’s worth of orders? Gut-wrenching, nowhere to go. This is a crisis by all accounts.

Losing data can kill a business. Always back up your data, no matter how confident you are about what you are about to do. If possible, have the backups in 2 different places (storage is not that costly in 2024). 

CloudNordic, a Danish hosting company, lost all customer data in a ransomware attack, so not only did their business get killed, but several other businesses relying on CloudNordic’s services were severely impacted.

I know this is unthinkable for most non-technical stakeholders, but it can happen. It could be a ransomware attack where you need to pay a ransom to get your data back, a rogue employee, or a mistake made by a data engineer who did not think it through. Imagine navigating your business without 5 years’ worth of data.

1.2) Data is likely the first bottleneck

Multiple apps hit your data source, so this is likely the first thing you’ll need to scale.

Let’s say you own a shop with an omnichannel presence, a physical shop, a web app, an iOS app, and an Android app. It would be weird to buy a voucher from the physical shop and not be able to use it on the web app, wouldn't it? Maybe that’s not the best example, as some shops still exhibit those domain boundaries, so shop-issued vouchers can be used exclusively within the premises of a shop; however, in 2024, users do expect to be able to use that voucher anywhere your business has a presence.

Let’s keep it in the online realm. Wouldn’t it be even weirder to see the orders you placed on mobile only on the mobile app and not when you checked the same shop via its web app too?

All the different apps hit the same database, so it’s natural for it to be the bottleneck and the first thing you need to scale; that’s why the decisions there can be costly.

1.3) Data solutions haven’t changed much in decades

With modern solutions like Supabase, data became friendlier, but the underlying technologies used by these modern providers are the same old-school relational or non-relational data.

You can’t go wrong with battle-tested solutions; you have full control. If you don’t know what to use, then go with SQL. The gap between non-relational data (or NoSQL) and relational data (SQL) has been narrowed with the introduction of JSON in SQL databases.

2) Use architecture to your advantage and code wisely

Focus on understanding the big picture and the implications of what you are building, and keep a list of each tool that you bring into your application.

Rather than wasting time analysing each insignificant business requirement, decouple as much as possible and aim for flexibility.

2.1) Never expose the raw data models

A lot of frameworks provide an ActiveRecord type of implementation that is very simple to operate; however, this shortcut can backfire, and it can backfire hard.

Exposing the raw data model to either read or write operations is never a good idea. Always use a data transfer object or proxy model, even if, at first, the proxy model is a duplicate of the raw model.

Having this proxy model allows you to:

• set up different validation rules
• add custom fields that can be used for arbitrary logic 
• rename fields for friendlier choices
• remove sensitive fields like the password hash of a user

2.2) Don’t be afraid to repeat code

Conditioned logic is not always bad, but it usually opens the door for more conditionals which makes things a lot harder to follow and can serve as a breeding ground for regression bugs.

By making use of software design patterns, you can come up with more elegant solutions than conditionals.

However, when in doubt, copy paste is not a bad choice either. It’s a lot easier to maintain 3 separate implementations for 3 use cases than 1 poor implementation for 3 use cases.

Sometimes, even the common ground the 3 use cases initially appear to have can be deceiving. As a rule, if the use cases share 20% or less and look like they may change, decoupling the logic entirely via brutal copy paste is better in the long run than trying to be smart about it.

2.3) Don’t be afraid to hardcode some things

Some business logic will never need to change. Don’t assume everything needs to be configurable.

If you have a finite list of industry or business terms, use hard-coded lists; it makes it easier to navigate requirements. Don’t assume you’ll need the flexibility of solutions like the entity-attribute-value model.

If, at some point, you do need to move the configuration to a more flexible place like a database, you will be able to, but until that’s needed, avoid premature optimisation.

3) Do not underestimate execution - Hire someone with a proven record

If you want to build a custom app, finding the right partner for that journey is as important to the app's success as your vision and ability to sell it.

Here at Oxentree, we shipped dozens of custom apps, and each of those taught us lessons that now serve as a foundation for the custom apps that are to come. We build cost-effective solutions that scale without giving up on quality and maintainability. By default, we also provide a warranty on the work and long-term support.

Everything's custom which means the sky's the limit. We don't do low-code or no-code solutions. 

Let’s chat about your project, whether new or existing; email us at contact@oxentree.com or use the form below.

Note: If you have an idea but don't have the budget for a startup and would like the expertise of a technical co-founder, do message us; we may be able to work something out. You can also give Y Combinator Co‑Founder Matching a try!