How much does it take to build an MVP with PHP/Laravel?
In the previous article, How much does it take to build my own SaaS platform? we’ve covered the basic concepts to have into consideration around software development for putting our business online.
We’ve noticed the difference between product (your resulting software) and project (the process of designing and building that product). The key event that separates the initial build from the business as usual phases is the product launch.
Among the many steps of that process, one of them is picking the right toolset. This decision has a direct impact on (and thus is based on) subjects like licensing, learning curve of the technical team, reliability, security, pricing, versatility, etc. While there are lots of tools and techniques to decide about, the programming language and framework are foundational parts of the technological stack.
In this article, we’ll assess the journey for building a typical web application assuming we have picked PHP for the programming language and Laravel for the framework.
You are not alone
The next important point we have highlighted is the need of properly scoping the requirements of the project. This is critical in order to avoid suffering from feature-creep.
Feature Creep: the excessive ongoing expansion or addition of new features in a product. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.
The risk of feature creep in the early stages is depletion of project resources and never reaching a ready-to-launch state, thus preventing the online business to ever start rolling. Having a standard definition for this phenom means you are not alone. It happens all the time, and unfortunately most of the time as well.
Scoping right is not an easy task, and while there’s no paramount standard to do so, there are some basic guidelines that the industry has proved to work pretty well. There’s — for instance — a useful and easy to follow article that I like, called How to effectively scope your software projects by Angela Zhang.
In addition to this, I personally like the concept of MVP (Minimum Viable Product) that we have already covered. There are, as well, lots of interpretations for MVP, so I’d like to share what it means to me and how I get benefited from using it in my own projects.
The probably most spread idea of MVP is about validating your business idea within a small group of users. In other words, you can actually afford to launch. This way, I see the MVP as the shortest possible path-to-launch, where I can make sure that my product sells and starts developing a real and active user community around my product, willing to use and back it. Once there, I can keep on building incrementally through new iterations.
Launching early vs not launching at all
Every typical web application has a set of steps that need to be addressed in order to go live. This is, for example: developing the web application, buying and setting up a domain name, buying and setting up a server (hosting), provisioning the web application, etc. These tasks can also be expanded into more detailed subtasks, and — the more detailed they are — the easier is to get an estimate.
Of course, there is no point in launching a useless, work-in-progress application to be available for your users. Remember those old-days website under construction banners?
Fortunately, modern web development has evolved a lot in this aspect. Nowadays it’s a good practice to code and deploy (build and publish — in more friendly terms) with the least impact to your users. Most of the time (when done right), they won’t even notice there have been changes taking place.
The “Under Construction” banner should be replaced by a working prototype of your product. This is the MVP; a minimal yet useful version of your full-fledged premium goal product. The trick is, users are already solving their problem with your application, and they are also willing to pay you back and spread the word. A win-win outcome.
I suggest you read How to Build an MVP the Right Way in 2018 by Swarnendu De, who goes deeper with great hints and also introduces the term MMP: Minimum Marketable Product.
Getting Hands On
Ok. You are probably willing to get some numbers about how much does it take to launch an MVP built with PHP/Laravel.
I will answer this question based on my own experience as a consultant and web developer, and assuming that we have perfectly understood why scoping is important.
A second important aspect to know is that building a software product involves many different type of tasks: analysis, design, coding, testing, validating, documenting, devops, to mention a few.
From the Project Management perspective, it is always expected to have as much documentation done as required before the actual coding. One might think that writing plain english and drawing diagrams would only waste time and money, but they are actually the team compass that help ensure everybody is on the same page.
A typical Laravel application follows a very common design pattern called MVC (Model View Controller), which are the building blocks of the application. The more features we want to add, the more complex our software is, and this typically requires creating new Models, Views and Controllers. This results in a reasonable increase of team effort and maintainability challenge.
While there is no fixed number for what a small application is, I’d say it’s that on which you can start operating with the least number of building blocks.
Let’s put an example. Imagine that I wanted to sell tickets for events. A full-fledged sample of this could be Eventbrite. If I wanted to build something suchlike, I’d be willing to add the following requirements for my product as well (taken from the main features of Eventbrite):
- Automated reminders
- Bar-code scanning
- Custom badges
- Custom venue maps
- Dashboards
- Easy refunds
- Event dashboard
- Event design listing
- Event promotion
- Automated promotion
- Event registration and ticketing
- Fundraising and crowdfunding
- Group registration
- Mobile event app
- Online payments
- Online sales
- Private events
- Recurring events
- Reporting and analytics
- Reserved seating
- Speaker profiles
- Surveys and audience polls
- Social marketing and Facebook promotion
Trying to get all this done in one move would be the best way to shoot myself in the foot. As, from the technical perspective it requires lots of Models, Views and Controllers (not to mention many other technical details that are skipped in this article for the sake of simplicity).
Having a standard definition for Feature Creep means you are not alone. It happens all the time, and unfortunately most of the time as well.
Opposed to this approach, I could just launch a very basic working version of an event platform and start selling straight away:
- Event listing
- Online booking
- Online payment
You might be asking how to see your yearly reports if no dashboard feature exists just yet. Good question!
Remember, your userbase is small enough at this point. It’s unlikely that your platform will hold enough activity data to generate a yearly report past 3 months of going live. Software development done right is costly, and unless you have unlimited resources, it looks more strategic to do things that don’t scale until developing a dashboard naturally stands out as the most cost-efficient way to go.
Feeling curious? There is realworld example; an open-source ticket selling and event management platform built with Laravel called Attendize. Take a look!
Give me some numbers
Now that we know that we’d use just a few entities for our application:
- Event
- Attendee
- Ticket
Now, we need to think of a core feature of our platform. The one that tackles the painpoint of our users and make our business sustainable (viable). This can be expressed in plain english as a User Story:
As a guest user, I want to visit the landing page of an event and be able to register to that event and pay through PayPal.
As a registered attendee, I can now access the event-details page.
Now we can think of a reasonable amount of time to develop and launch. Why? Because all applications are born from barely the same boilerplate code and they look pretty much the same during the early stages. It’s easier to have statistical data about it’s development phases.
Time
An average small scale application in Laravel can be built by a single experienced developer in a reasonable (finite) amount of time. Depending on his skills and creativity, and how strict are the quality requirements of our project, it could be around one day to a couple of weeks. Apart from the feature development itself, it’s required to set up some infrastructure elements to let the application live somewhere. That may take an extra day or week, depending again on the tools and requirements we stated in first place.
In my case, I could build and send live an MVP application for special meals ordering in about 80 to 120 hours.
Is it perfect? No.
Is it full-fledged? Neither.
Does it solve the core problem? Yes!
Has it enabled the business to sell more? Of course!
Costs
Cost estimation is a matter itself. There exist lots of techniques and books about it. Here I’ll delineate a simple way to get a rough estimation that should work as a rule of thumb to determine if we are (or not) up to the task, before we get fully committed to it.
Now that we know how many manpower hours do we need, we can use it to multiply an hourly rate, or we could otherwise think of a weekly or monthly fixed rate. That will depend pretty much on your agreement with your favorite web developer.
If our developer charged (say) USD $25 / hr, we could think of USD $2000 to USD $3000. These rough numbers also make sense if we wanted to hire someone for two months. Again, this depends on the agreement you have reached to.
You should also add some infrastructure base costs, for example a domain name and a web server.
- Domain Name: USD $12.99 / year
- Web Server: USD $60 / year
These, again are sample numbers based on a Hover search for the Domain Name, and the smallest droplet plan that Digital Ocean offers.
Conclusions
Scope, Time and Cost conform the project triangle we need to put together.
The better we scope, the easier to estimate times. Once we have times, we can estimate manpower costs, which (when hiring) conform the most expensive asset in the development of our web application.
Needless to say, budget will largely depend on your negotiation skills, technical management knowledge and quality expectations. The smallest budget one can get will never reflect the results of the full-fledged solution we have in mind. It’s only a baseline to let us know if we are willing to start or not with our project until we launch, and then continue developing for our user community based on our business model, and knowing that we’ll need to re-invest in further development if we want to improve and add new features to our product.
Need help with scoping your MVP? Tell me about your project plans on the comments below or private through Fiverr.
