How much does it take to build my own SaaS platform?
The answer to the ultimate question of life, the universe and what it takes to build your own SaaS platform is 42.
TLDR; This article is aimed at Clients, Solopreneurs, novice Project Managers, and Product Owners struggling to get a customized web application built and ready for action.
If you have already decided to work with PHP/Laravel and are already familiar with the big picture, you may skip directly to the Part II.
Imagine you are willing to run your online business through a custom web application. Maybe it’s an online store, a learning platform, or a special membership website.
So far, so good, but in order to get it up & running, you first need to build it.
As a web developer, you could start coding straight away. But as a non-technical client, you’d need to hire someone else to do this for you.
If this is the case, but you’ve so far spent months spinning and spinning with little actual results, you might be missing some important details about how online business and web development play together.
Let’s begin by asking Wikipedia for a definition of some core elements in this article.
Online Business: Any kind of business or commercial transaction that includes sharing information across the Internet.
Web application: In computing, a web application or web app is a client–server computer program (software) which the client (including the user interface and client-side logic) runs in a web browser.
Software as a Service (SaaS): A software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. It is sometimes referred to as “on-demand software”. SaaS is typically accessed by users using a thin client, e.g. via a web browser. SaaS has become a common delivery model for many business applications, including office software, messaging software, payroll processing software, DBMS software, management software, CAD software, development software, gamification, virtualization, accounting, collaboration, customer relationship management (CRM), Management Information Systems (MIS), enterprise resource planning (ERP), invoicing, human resource management (HRM), talent acquisition, learning management systems (LMS), content management systems (CMS), Geographic Information Systems (GIS), and service desk management. SaaS has been incorporated into the strategy of nearly all leading enterprise software companies.
Note that a SaaS is also called -from the business perspective- a “platform”.
So, in other words, you might be willing to build a web application and deliver service through that software so that you can run your own online business platform.
These platforms also have a well-defined triangle of user roles:
Service Providers: Users that bring value to your business by providing valuable services.
End Users: Users or customers that consume those provided services through the platform because of its value.
Administrator: Users that monitor the platform activity, providing technical support, and getting reports of the business growth. Sometimes, also the owners of the entire platform.
Now that you know that you want to build such a SaaS platform, you might also identify which of those roles would apply to you. Maybe you’d be an end-user consuming your own dog food. Maybe you’d provide some services along with other providers. But for sure, you’ll want to be able to support, monitor, maintain, enhance, and manage that platform. In the end, it’s your own dear craft.
Say hello to “The Product”
All of these definitions would make great sense to you if such a custom platform already existed. And because it doesn’t, we can’t speak of a platform just yet; we speak of a product to be built; a thing that will be the result of an action or process.
But there are even more roles that play out outside the scope of the product. Since the product does not yet exist, let’s take a step back and stand into the process.
Since hardware is tangible but the software is not, one might be tempted to think that to build software you need a web developer and magic foam. Well… I don’t blame you. That was kind of true during the baby steps of the Internet until around 1995. Your webmaster (the nowadays so-called web developer) would craft something like this for you:
<!DOCTYPE html>
<html>
<head>
<title>Your brand new website</title>
</head>
<body>
<p>Hello world!</p>
</body>
</html>
The problem started the day you wanted to change Hello world! for Hello John! depending on your client’s name, add some color and let him pay with his credit card over his mobile phone. And as such things started to be possible through programming languages, it also started to become a more and more complex task.
Say hello to “The Project”
Building a software product is kind of comparable -up to a certain extent- to building a house.
First, thinking of the purpose of our product; if you’re willing to provide services through it (cause’ we said SaaS, right?), it will probably not work as a house but as a hotel.
Second, we’d then need to determine what type of building we want for our hotel: a shack? a cottage? a castle maybe? a skyscraper?
Great! We now have at least an idea of what we want, something we can communicate in a way that someone else could think of.
Unless you go with the shack by grabbing your own shovel, you’ll need to document that idea so that someone else can actually build it. You’ll probably need site plans, a floor plan, elevations, section cuts, foundation plan, framing plan, sub-floor plan, roof plans, including type, pitch, and framing, interior elevation, detail drawings, schedules for elements, structural layouts, electrical and telecoms drawings, plumbing schematic drawing, etc.
Not only you’d need all those plans, but also the materials, the tools, and some competent people that could execute that plan: think of architects, carpenters, urban or regional planners, electricians, construction managers, construction, and building inspectors, roofers, etc.
And finally, you’d also need a guest who would live in it (this is your End User).
Now guess what? Making all that people execute that process successfully takes effort, time, and money.
Now you see you’d also need someone who would afford to make that process spit out a good product (and this is the Investor).
Say hello to “The Project Manager”
So far so good, no need of much expertise to notice the basic questions that should pop-out before any hotel construction:
How do the target guests look like?
What type of building?
Which roles to hire?
What materials to buy?
How long will it take?
How much will it cost?
The act of answering those base questions (and many more) is called Project Planning and Project Management.
If you are going to use the product for consumption, you are a Customer, Client, or End User.
If you are going to use the product for selling or providing a service, you are a Service Provider.
If you are going to give the product an advanced internal use, you are an Administrator.
If you are going to afford the product construction, you are an Investor or Sponsor.
If you are in any way interested in product success, you are a Stakeholder.
If you are in any way going to orchestrate all this process, you are the Project Manager.
If you are going to own the product, you are the Product Owner.
Say hello to “The Project Charter”
If you made it here, we may conclude so far that for building a software product we need at least a documented and scoped requirements (quality), a skilled team (people and roles), the right tools (technology stack), a plan (time) and a costs budget (money).
All this information perfectly fits in a document that the Project Management Institute (PMI) calls a Project Charter, and its purpose is to best possible fill the gap of the triangle of death of the project.
We will cover the Project Charter in detail in an upcoming article.
Say hello to “The MVP”
We now know that for building our hotel we would first need to write down all of the specs on how it would look, how it would operate, how many floors, rooms, amenities, and such would have, and a long list of, etc.
If we picked a skyscraper as a goal, it makes sense to think that we would require much more effort, time, and money than if we picked the shack.
At this point, we are thinking big, but we don’t even have our first guest.
Which would be the shortest path to get there?
Sticking to a building type that fits into our mind and that we could handle according to our management expertise and needs for an early launch, would be a good choice.
This is where the Minimum Viable Product (MVP) concept comes into play.
There exist a lot of good sources explaining what an MVP is and how to achieve it. Here is one I like from ClearBridgeMobile.
But for now, I’d like to emphasize what I understand and take of this concept for my own projects.
Product: A piece of software that actually works…
Viable: …and solves at least one core problem for actual paying customers…
Minimum: …by having invested the least resources (effort, time, and money) to get that product.
So that once we got there, we can keep on improving and scaling-up that platform gradually.
Conclusions
To build a web application there exist proven methods that the industry has developed over time. That resulting application should be called “product” and the enterprise of making it happen “project”. Doing the math for the time it takes is called planning and for the money, it’s called the budget. But in order to get those numbers, it’s needed to define a scope for the requirements that will result in the quality of the product. If we are willing to make those numbers be the least possible, we can use the MVP concept to walk the shortest available path-to-launch and let the first real users get their job done.
In the next article, I dive into the details of planning an MVP in Laravel, provided that we already have a Project Charter, and have picked PHP/Laravel as the foundation technology for our platform.
