DEV Community: H-J Johnson

Can it scale? (First Part)

H-J Johnson — Sun, 16 Aug 2026 17:46:17 +0000

I will do my best to clarify what the term ‘scale’ (actually) means.

TLDR

Technology Scaling is not Business Scaling although they can work together for success
Servers / Infrastructure is a tiny fraction of the overall scaling discussion
Servers / Infrastructure falls under Technology Scaling
All the servers in the world does not mean you are scaling
Core Code + Delivery is the ordered combination that should be followed to achieve technology scaling
There is a side of the scaling conversation that involves physical locations!
Business Scaling is another ball game that I might address much later

Let dig in!

The questions ‘Will it scale?’ and ‘Is it scalable?’ are very common in the software product / technology domain.

A lot of people just think of only servers and infrastructure. There are groups of people that only think physical locations and nothing else. Most people are just outrightly clueless and do not even know what they mean when they talk about scaling/scalability!

Allow me to guide you beyond buzz words and theories (ahem ‘blitzscaling’). When addressing the question of scale think of two main categories, namely:

a) Technology

b) Business

Technology scaling is not business scaling and vice versa. However, if done correctly both can work hand in hand for greater success. I will tackle technology scaling first then later in subsequent parts, I might break down business scaling.

Let me start this technology scaling lecture with laying a foundation by saying this, if you have all the servers in world, all the cloud instances in the world and the core of your software product is in shambles you cannot scale! In such situations, when asked if you can scale you should not answer yes, at all.

For any software product to scale technologically, you require two things: 1) Core Code 2) Delivery. These two (2) areas are what you should consider when talking about technology scaling.

To understand this, consider two sides of the spectrum: Side One, making software for others to use. Side Two, relying on software to thrive. Stay with me I don’t want you to get lost. This is building on the foundation laid above. I will start with Side One to explain technology scaling.

Side One (Making software for others to use):

Consider a company that provides a solution to other companies. Company A has Client A as a customer. Client A is a good customer and wants to recommend Company A to members of their association. So, twenty new customers approach Company A but their Core Code is not as it seems. To carter to the twenty (20) new customers, Company A has to fork the code base each time. So now they have twenty (20) different codebases, one for each of the twenty new customers. Company A realises they are in soup and cannot take on new customers. They cannot scale because their Core Code cannot scale. Their Core Code is not scalable so they aren’t scalable! Any new customers that come along means newer forks so they simply turn them down. Do you see where this is going? Not yet? Keep reading. Now for each customer that Client A helped bring in they have servers doing server things (cloud, serverless, whatever). All the compute, storage, database and networking Company A deployed for each customer makes it seem that their solution scales, but that is false!!

Side Two (Relying on software to thrive):

Consider a company that needs a solution to aid them accomplish amazing things in their industry quickly and without hassle. Company B meets Vendor B to adopt a solution and move on with their activities. Along the line they (Company B) realise every simple tweak needs the software vendor. They cannot create extensions, plugins, other things that will give them some sense of freedom as users of the software. As if that is not emotionally draining enough this company’s users keeps growing but the Core Code from Vendor B is not allowing Company B to soar as their user base grows. Apparently, the vendors of the software (Vendor B) did not design it for massive use but rather for a company with no intention to grow to millions (and even billions). Ouch!

With the spectrum laid out atop the laid foundation (I think) you should better understand technology scaling. There is an order of things to achieve tech scale. And that order is Core Code first then Delivery second (it’s ok to disagree with me but my experience has shaped this opinion). Most people make the mistake of discussing parts of Delivery and think they are addressing the scaling question but that is a huge mistake! I will do my best to describe Core Code and Delivery below:

1) Core Code: this is the code at its core! How it is designed, written, structured and organised. This is where the scaling analysis begins (or in my opinion, must begin!). If this box is not ticked (and ticked well for that matter), forget any servers or cloud infra you have in place. If you are a software vendor/author, take out considerable time to address this part of the scaling discussion. If you are an organisation shopping for software, ask questions about this area. So, what makes a great/solid Core Code? Over the years I have created a detailed checklist of areas that needs to be addressed but I’ll list a few pointers here. These pointers take the form of questions and statements that will serve as a guide. I will also try to use examples existing in the market.

Statements: Never confuse setting up and signing up as the same thing, they aren’t. A solid Core Code is not custom built for just one person but rather for the general market with the liberty to modify per their needs. A system with a solid Core Code has to be API first and the APIs have to be error first APIs. Being modular really helps in keeping a clean codebase at the core. A solid Core Code will evolve into a community that includes not just users but service providers and developers as well. A great Core Code is delivered by a solid and well thought out development pipeline. It is not every type of software that will need to provide a system for the masses to create plugins but internally it is a useful way to move quickly and efficiently.

Questions: What is the setup process of the software and how easy is it to complete? How easy is it to signup? How are accounts managed after signup? (Individual accounts, company/organisational accounts, accounts hierarchies and possible transfers, accounts cancellations/deletions, accounts updates/modifications). What are the defaults for every action along the way? How will pricing be enforced/implemented? These are just a few questions.

To further understand ‘Core Code’ in the way that I see (and understand) it, I will use one of my favourite opensource projects, Drupal (I will not discuss Acquia here). Every user gets a foundation copy of the software and sets it up in their own environment. It is not a custom software for only one person/organisation. Typical of any solid Core Code is the foundation copy given to users. This copy is usually a plugin architecture that enables the users to build their own modifications (modules, themes, distributions) or obtain one from any trusted marketplace. This freedom offered by the software allows users to address any needs that may arise. It does not lock down the vendors to just one user but allows multiple users to get the software. It also does not cage the users as they can modify the software by adding new capabilities. Achieving solid Core Code for SAAS vendors is somewhat different since they want customers to use the software on their domain (ie the vendor domain). But the idea is relatively still the same. Give the user a foundation copy and the option of adding modifications (created by them or obtained from a trusted source). Think Shopify and how we now have Shopify developers and a thriving community. There are other SAAS vendors in other areas asides ecommerce that give their users such freedom.

In the most basic form this is what it means to be able to scale at the Core Code level of the software! A foundation copy, the user can then extend/modify per their needs/use cases!!

2) Delivery: the means by which you get the software product into the hands of the user. If this box is ticked and the Core Code is not ironed out properly then (in my opinion) you have a problem! Delivery is basically how your product gets to the hands of customers in the market. Delivery is easy when your Core Code is in order from all perspectives (design, processes, architecture, etc).

Back in the day CD-ROM was the way many vendors got their software in the market for the customers to purchase. Then some software authors started providing copies via downloads from their website. These days you can visit a vendor website to download an installation file. Some vendors simply have you use the software on their website without the need to download anything or leave their website (ahem ahem SAAS)!

You can choose just one method of delivery eg only CD ROM (this still exists today), only installation downloads from the website to the users’ computer, or only allow entire software usage on a website so there is no need for user downloads (basically SAAS). OR

You can choose a combination of methods eg provide CD ROM for users but to complete the setup the user has to be connected to the internet to retrieve vital information from your servers (also useful for updates after CD ROM installation), installation file from the website that connects to the internet during the setup process, provide the user the software on your website but provide an offline mode so the user can use it without internet connection, provide installation via your website but also have a version that allows the user to do their work on your domain as well (Microsoft does this with MS Office where you can install the software on your computer but also use it on their website as well). Allow the user to install the website on their computers so when they tap the icon it opens your website (PWA basically).

This is Delivery, the part of technology scaling that finds ways of getting your software to the customers. The mistake people make with delivery is they jump straight to SAAS and close their eyes to various other methods of ‘Delivery’ (what can be learned or perhaps combined together). They jump straight to the server/infrastructure conversation without asking how individual users (and their activities) will exist on their domain.

The Delivery bit is where people start (and end) the scaling conversation, and it is so wrong! Imagine having a horse push a coach with you inside it. You keep beating the horse because you feel it isn’t pushing the cart properly and fast enough. That is what is happening today. For goodness’ sake the horse should not be pushing the cart!!

Do you remember the two spectrums from earlier? Side One and Side Two (the ones laid atop the foundation statement)? If the software vendors/authors followed the order of having a solid Core Code and then easing into an in-depth planning of Delivery, then actual distribution of the software will be easier thus achieving technology scale. This way the vendors will not be locked to one user (or a hand full of users) and targeted customers will not get stuck along their journey in using a vendors software product. This is valid for any type of software product across any business model (B2B, B2G, B2C, etc).

Most people have not understood the problem deeply and thought through how to put in place Core Code to address the problem and how in-depth Delivery plan will further support this Core Code. But they jump into talking servers/infrastructure (which is a small piece of the overall Delivery discussion). And it is usually in the line of: … a SAAS platform with adequate server instances ‘so they can scale’, let’s use microservices ‘so we can scale’. With the excuse of “moving quickly” many software authors have skipped critical steps that needs to happen, in favour of trends and buzzwords. It is terrible to watch.

To scale technologically you need to follow an ordered combination of Core Code + Delivery. Your Core Code first then the Delivery second. This is not a surface level conversation. You should have a deeper conversation into these areas individually and as a whole combination. This is what it means to have technology (at) scale.

I am interested in hearing your thoughts about my opinions on the scaling conversation. In what area do you disagree? Do you find it misleading or is it a great guide? Is there anything you want me to further explain?

In another part of this opinion piece, I might address another category of the scaling conversation, Business Scaling.

Don't do Product without Project!

H-J Johnson — Wed, 14 May 2025 20:26:10 +0000

Don’t do Product without Project!!

Don’t do Project without Product!!

In our ever changing world you are better off being results-oriented and methodical.

Whether you are working on a software, or a hardware, or a service or perhaps a combination of ALL three. Do not do one (Product or Project) and neglect the other! Do not leave out Product because of Project and vice versa. Be careful out there. Do your Project with Product. Do your Product with Project. One is NOT superior to the other. They both have their purpose individually.

Many newbies have never heard of the term Application Lifecycle Management (ALM) and it’s very sad for them. Many of these same newbies have never heard of or understood how SPM (Software Project Management) was meant to aid SE (Software Engineering).

Rather than trying to pit Product against Project or Project against Product, I am here to tell you that both can work hand-in-hand to achieve a successful solution to a problem.

Take my guidance, I have been here for quite some years now.

Learn to pick (and combine) aspects that is useful to you and works perfectly to your cause. If it works and is useful, go ahead and apply it. If it weighs you down, drop it. Your end goal is to arrive at a solution to an actual/existing problem!

Doing Product Management with Project Management (and vice versa) allows to be results-oriented and methodical.

📜 Read my stuff: https://lnkd.in/dUd5GasK
🤼 Follow H-J Johnson and hit 🔔
🔎 LinkedIn | Medium | Substack | DEV

Vibe coding, not the way, NOT the answer.

H-J Johnson — Fri, 25 Apr 2025 18:34:58 +0000

Vibe coding is NOT the answer and it will NEVER be the answer! With over eleven years in the IT space, I say that confidently. When I read about it, I knew it was another trend that will fizzle out at some point. Personally, I feel we should give the inventors of the vibe coding concept a point for effort. I mean that’s ‘e’ for ‘effort’, yes? We can all assume they were trying to help by creating something that will assist us move quickly and become better with our work, in this industry.

If you are building a technology offering, be it software, hardware, service or a combination of all three what you need is methods that are tested and battle ready. What you need is balance between thinking and action. Balance between theory and practical. Ask yourself: What and how are you thinking? And why are you thinking that way? What actions are you taking? How are you taking those actions and why? You do not want to over think or spend your whole time thinking also you do not want to over act or spend your resources moving in the wrong direction and doing the wrong things.

So now, how do you balance thinking and/with action? Where can you find and see this balance? How can you balance theory with practical? Does it even exist? I say, you can find this balance in the (battle ready, tested and trusted) Iterative and Incremental methodology!

This methodology does not neglect the SDLC. It uses it very well!!

Vibe coding is not the answer! Do this instead.

Allow me to give a very simple and brief look into what balance looks like.

THINKING & ACTIONS
THINKING:

Questions, ask questions! Is this a real/actual/existing problem?
Is this what I should be doing? ACTIONS:
Research! Things like: go out and talk to real people (surveys, interviews), focus groups.
Putting form to ideas. Things like: sketches, POC, Prototype.
IP Protection. Things like: patents, Copyright!
Actualising the idea beyond its first/initial form. Things like: MVP, soft launch, early bird access.
Integrated Marketing. Things like awareness, hype, whatever, PR, Sales.

THEORY & PRACTICALS
THEORY:

Statements like ‘technology makes work easy and smooth’.
Statements like ‘build it and they will come’.

PRACTICAL:

The theoretical statements above might not be entirely true in certain situations. You need some practical evidence to show what needs to be done!
Don’t build until you are sure people have the problem and will pay for YOUR solution. Talk to real people, do genuine research.
Practical design decisions such as: o Go completely electronic or have paper trails and paper backups. o Use Bluetooth, internet for communication, data transfer. o What will work here in this use case, in this operational environment? o Should there be offline mode and to what extent?
Technology in a certain use case/scenario/environment; is it really helping or is it hindering/slowing the work down. In areas such as restaurant management, auto shop management, farmers selling in the market, sending/receiving money in remote areas, making payment in remote areas.

This balancing act will happen as you go through the SDLC (Software Development Lifecycle) using the Iterative and Incremental Methodology. Several iterations (and increments) will occur as you use the SDLC until you are truly ready to face a larger audience and/or market to sell your product/solution.

Critical thinking is crucial. Situational awareness (and analysis) is very key to maintaining balance in a healthy way. With this approach you derive many benefits such as:

Avoid moving in the wrong direction.
Avoid building the wrong thing.
Overcome overthinking/analysis paralysis.
Gain proper System Design, Design Thinking, Service Design.
Avoid funds misallocation and mismanagement.
Proper documentation for actions/activities.

So, in summary:

Balance NOT vibing!
Iterative and Incremental methodology.
Utilise SDLC stages armed with critical thinking and situational awareness.

📜 Read my stuff: https://lnkd.in/dUd5GasK
🤼 Follow H-J Johnson and hit 🔔
🔎 LinkedIn | Medium | Substack | DEV

That’s not an MVP! NO, it’s NOT!!

H-J Johnson — Thu, 24 Apr 2025 06:07:40 +0000

Newbies in Product Management (and the IT/Software space as a whole) are being led astray. I consider myself to be blessed because I learned the correct fundamentals and basics on subject areas that are today misunderstood and misinterpreted. One of such subject areas is the concept of an MVP (Minimum Viable Product).

There is this image that is used to depict an analogy about MVP (Minimum Viable Product). There are several variations of said image, but I won’t dwell so much on the image, the analogy and all that is wrong with it. Why? Because I want us to talk more about the correct thing.

So, let’s understand. What is an MVP? It is the most basic, working and useable version of your idea that you can deliver within a set time for customers to use as solution to their problem not minding whether they have to pay or not and also gives you some chance to gain a foot in the market. An MVP is basic and it works better than a Prototype or a Proof of Concept (POC). Sometimes the gap between a Prototype and an MVP is wide, other times it’s just a small gap and in some (rather rare) cases the gap is so small you don’t even notice it.

To create an MVP, you first have to decide what it is that you are making/building. Is it software, hardware or a combination of both? Please note, you do not start building an MVP when you have not done proper research and feasibility studies to ensure what you are tackling is a real/actual/existing problem. During your research phase you use POCs and Prototypes to aid your research, feasibility study. Ok, so you have decided what it is that you are building, I usually advice at this stage you can (and should) still make sure what you are doing is an actual solution to a real/existing problem!! Now ask: What is the most basic thing your product can have that you can give to the customer as a solution? MVPs are not set in stone! MVPs are based on an understanding of the problem you are trying to solve, the situation you are in and the conditions that exist in the terrain or business landscape you are venturing into.

If your product is a scooter your MVP should be a basic version of THAT scooter!
If your product is a car your MVP should be a basic version of THAT car!
If your product is a wheelchair your MVP should be a basic version of THAT wheelchair!
If your product is a HR software your MVP should be a basic version of THAT HR software!
If your product is a fintech app your MVP should be a basic version of THAT fintech app!

By now you get the idea.

You do not start out trying to make a scooter and end up with a power bike. That is not an MVP!! NO, it’s NOT!! You do not start out trying to make a motorcycle and end up with a car. That is not an MVP!! NO, it’s NOT!!

All the stages you see in those misleading, misinformed, confused images are incorrect. MVP builds on lessons learned from your prototype and/or Proof of Concept during your research/feasibility study. Those lessons then translate into an answer to the question: What is the minimum that we can put together to give to the customer? Like I stated earlier it is not set in stone. Do a situational analysis, look at your research and the results of the research (POC and all). What is the most basic, working and useable state of the Product that you can deliver to the customer? Put those things together bring that basic, working, useable state into reality and that is your MVP!

Your MVP sets the stage for you to build newer improved versions of your product. Just ensure you stay close to the customer/users and continuously collect feedback. Compare the feedback with insights from the larger market/industry and you are on track to being a major player in your chosen field.

So, a quick recap:

MVP is a basic working, useable version of your product.
It builds on lessons learned from research, POC, Prototype.
You need to understand the problem very well.
You need to understand the market.
It is not set in stone.
You do not start out creating an MVP for one thing and end up with another thing!
MVP is a structure upon which to build newer, improved versions of your product.

Hopefully, this simple explanation clears the misinterpretation of what an MVP means. And you never have to worry about its true meaning.

📜 Read my stuff: https://lnkd.in/dUd5GasK
🤼 Follow H-J Johnson and hit 🔔
🔎 LinkedIn | Medium | Substack | DEV