What I learned about the team building a SaaS app

Any service or part of the software you need to build or learn as a team takes time. Often time away from something of value to the product.

Author:
Category:
mailing
Reading Time:
4m 28s

Start with your team members work as far apart as possible

First, let one or two build the groundwork and get to the point they have refactored some patterns that can be learned and copied. With your team members work as far apart as possible, but on the same page.

I saw the value in this when myself and the lead developer had bumped and tested some core objects for 4 weeks on the MVP phase. Scaling this work out to two other developers was then easier as the 10 more processes could be built out to follow and improve on these patterns. If four developers had all had the same task early on then would would likely have not gotten the same team sharing but four slightly different patterns.

So get case history and reasons for why early as you can, then double down on those after. Same as you would for being lean with the whole project start with small and what you need first.

Don't build any service you don't need until everyone is complaining

Any service or part of the software you need to build or learn as a team takes time. Often time away from something of value to the product. If it is not core business need then use a third-party tool or service until you need to do or scale more than it is practical.

This pays off that you can plan the actions for email, crawling, testing, authentication, without having to go through the learning from scratch and having to support it after. You can grow your team capacity virtually by adding the server farm and skills of another team, for usually less than the hourly rate of a single dev.

Set a benchmark, of the percentage of the product running cost, or vs the monthly salary of someone new. If you need a service and it is costing £200 a month, but staff to build and support it in-house will be £3,000+ a month you are winning back time.

If you use a service do not tightly couple

Using a third-party service also encourages a loose attachment to coupling to the product. If it is connected at a suitable arms length and with testing and alerts it makes change easier to adapt for. Fewer points to change deep in the application mean your team can move faster, and not break things.

Product backlog will never be empty

The last point today is to know from the outset, you are not building something of a fixed size and function. The more you add to it the more it will inspire the owners and customers to want more and improve it.

A Product is a digital living machine, and can be changed and improved endlessly. So make sure you focus on the real world need and features for that phase rather than the task list being cleaned down.

When you have a website that you want thousands of people to visit, they will all be essentially the same person seeing the same pages. So though small items may change or adapt to the users, they are looking at your content in the same way. In an application it is your machine but their content, and they want it their way, and so use it in a different way or for different outcome. So guaranteed they want it their way. Result being a smaller paying audience but x1,000 new managers. If your customers are paying they like it to work right for each of them.

Photo Credit: David Pennington on Unsplash

#laravel #email #saas
Mautic Tags

See also