Building software can be a very expensive and risky venture, especially because of how quickly technologies change in the industry. The app you build today might become already old in a few years. Therefore, to minimize the risks, it's very important to have a very solid foundation, move quickly and keep iterating and improving the product.

Let's review step by step all the concepts, requirements, and processes we are using when building new software from an engineering and creative perspective, right from the initial requirements straight down to the product launch.

Most important high-level points the software needs to fulfill

• Satisfy a strong market demand

• Include the company vision/goals and the investors' priorities

• Be highly aligned with what the end-users need and want to use

• Provide an excellent performance, bug-free accessible user interface/experience, and clear information architecture

• Invest time in building clickable prototypes and validate the journeys and the core features with the users before starting development

• Follow the design system guidelines

• Release an MVP to production quickly

• Prototype quickly to cover as much terrain as possible and find out the extra things you will need that were not part of the initial plan

• Avoid premature optimizations. Validate your product in the market first

• Gather feedback from the early users and keep releasing new features in small batches

• Keep the maintenance and infrastructure resources and costs as low as possible

• Assemble a team that is set up for success

What defines a solid foundation

Like when building a new house, before the construction starts, the right group of people must be in place, with the correct materials, tools, and plan.

The ideal squad

Every project starts with a team. Depending on the available resources, size, and complexity of the project, the team would be big or small. For a new SaaS product of medium complexity that aims to operate globally, the minimum size of the team has to be around 10 people. That's a general ballpark figure. It can be very different depending on the circumstances and the skill levels. In any case, it is recommended for the team to include the following leading roles:

• Product Manager (sets the vision, goals, business trajectory, etc)

• Project Manager (sets the project scope, timeline, budget estimates, etc)

• Design Lead (creates the IA, wireframes, mockups, prototypes, etc)

• Tech Lead (creates the dev architecture, writes the technical docs, etc)

• SRE Lead (creates the infrastructure and reliability plans, etc)

• QA Lead (creates the test plan, writes test cases, automation, etc)

• Product Marketer/PR (promotes the product in several channels)

The rest of the team would be filled with QA/Front-end/Back-end/Reliability engineers and designers depending on the skills required to fulfill the project requirements.

If the Product Owner and Scrum Master roles are required but cannot be filled, they can be assumed by some team members with the right skills and motivation.

There are also some important points that sometimes are not talked about enough but can make a notable difference in the team efficiency:

• Split the team responsibilities clearly based on skill level and personal motivations. If necessary, rotate them once in a while to keep everyone engaged and motivated

• Foster a culture of ownership. Everyone in the team should be responsible for creating and owning something meaningful. Engagement is a key factor, especially in long projects

• The leading roles need to proactively make sure everyone feels included in the team and their opinions are valued. They also need to be effective communicators and leaders who apply critical thinking and problem-solving skills

Team and project setup

Apart from having a solid team, there are also certain aspects before starting a new project that need to be as ready and mature as possible to avoid delays:

• Infrastructure: all the code repositories, servers, testing environments, domains, 3rd party services, etc

• Project management software: ticket/issue tracker, boards, documentation site, calendars, resource allocation, team communication, etc

• Work methodology: the squad members should agree on which methodology to use and find the right people to handle the processes

• Domain knowledge: everyone in the team needs to use a ubiquitous language (use the same names/acronyms) and have a single source of truth to learn about the domain concepts

• Tech red lines: there are certain requirements that can affect greatly the final tech stack, like the need to support IE, SEO, bundle size, etc

• Design system: UI toolkit, guidelines for accessibility, iconography, typography, photography, etc

The design system

One of the most important aspects of building great software is to use a proper Design System and UI toolkit. Aside from guaranteeing design consistency and communication style across apps (Web, Android, iOS), websites, Social Media, and print materials, it also makes the products more maintainable through the use of reusable components. This also provides teams with the Lego blocks to create new prototypes and test new concepts and ideas using the same common visual and technical language.

It's fine to experiment with many different ways of creating products, from organizing teams into squads to using different work methodologies. Nonetheless, the design system has to be always at the center of every new project. it's like a Bible that is constantly being improved. Adapting to the changes in the industry and providing a single source of truth for the teams in the organization. If you take care of it, it will allow you to build products much faster and with better quality.

The work methodology

Let's quickly review the key differences between the most popular work methodologies:

• Waterfall: all the documentation is done in advance, including user stories, wireframes, mockups, and all the features’ variations and outcomes. The majority of the research is done upfront, estimates of the time needed for each requirement are more accurate, and this can provide a more predictable release date

• Agile: it requires less upfront documentation and planning. Features are planned along the way in a more collaborative way, including frequent reviews by the stakeholders. Changes that come further down in the process are less time-consuming, painful, and costly than with waterfall. On the other hand, the release date is more ambiguous. It can also include Kanban and Scrum methodologies

• Shape Up: it doesn't use daily stand-ups, sprints, or backlog. Time frames are called appetites, which are capped at 6 weeks and projects can not roll over to the next cycle. Like Agile, the scope is flexible to a certain extent

If you've been around for long enough in this industry, you have probably started your career using waterfall, then moved to Agile at some point, and after a few years, realized that there is still something missing. Perhaps Shape Up could be the answer for that missing piece in Agile. Read more about Shape Up.

At TableCheck, we have mostly Agile squads, although we are also in the early stage of exploring Shape Up. For now, these quotes from Mike Schutte and the Work is like a hill concept are something to keep in mind:

Instead of picking a direction as fast as possible and getting there as fast as possible, Shape Up encourages you to think carefully about the direction you’re going. To think critically about how you’re going to get there.

Instead of asking “how long will this take?”, you ask “how long are we willing to spend on this problem?”. The result of the latter perspective yields, I’d argue, more innovation.

Every product, team, timeframe, and requirement is different. There's no magic formula that can work for every case. Nonetheless, there are certain frameworks and work methodologies that allow more space for creativity and innovation than others. If you feel that the way your team works is not allowing you to give your full potential, then I'd suggest you have a chat with your peers and find a solution.

Whether your team uses one methodology or another it doesn't change the goal, which is to build software. At the end of the day, the team has to choose the approach that works better for them.

The ideal lifecycle of a product

Like Steve Jobs once said, and recently Addy Osmani reminded us:

You've got to start with the customer experience and work backward to the technology. You can’t start with the technology and then try to figure out where to sell it.

The best software is built by engineers who have empathy for their users.

The message here is clear: Focus on the user and the rest will follow.

If we were to start a new product today, the product and design track should be the first to focus on. The engineering track could also start at the same time to prepare the groundwork, but at some point, to start coding the real features, it would require the deliverables from the design team to start implementing them.

Product & Design track

1. Objectives / business discovery:

   • Project vision and objectives. What outcome do we want to obtain?

   • Business objectives and workflows

   • Measurement framework. Make sure analytics are in place

   • Team roles and stakeholders mapping

   • Project scopes

   • Spec writing: product spec. and functional spec

   • Prioritizing product features and capabilities to ship

   • Define core users and conduct interviews if needed

   • Define a list of focus areas

   • Package the requirements as sprints/projects/epics for design to work on

   • Sprint planning/milestones

   • User personas: qualitative and quantitative research by survey and by interview

   • Use cases/user flow

   • Existing user journeys and opportunities

   • Empathy map

   • Competitors and landscape analysis

   • Design then takes all the insights from the discovery work to start ideation, prototyping, and usability testing

2. Ideation:

   • Experience principles

   • UX trends/user behavior

   • Design scope writing and LOE (MoSCoW method)

   • Design sprint planning - what areas to start with first

   • IA and templates

   • Initial designs/wireframes

3. Usability testing:

   • Create non-code prototypes for testing with Figma or Maze

   • Conduct user testing of the mock-up and analysis result/reporting

   • Learn and iterate the design. Finalize test

4. Design Production:

   • Design annotation (if needed)

   • Package up assets for all variations

   • UI library - update the Design System

Engineering track

1. Gather the requirements from the stakeholders

2. Study the technical feasibility of the product

3. Decide the tech stack:

   • Front-end, back-end, and infrastructure architecture proposals

   • Code and discuss with the team any required POCs

   • Research required 3rd party solutions like CMS or analytics

4. Project management and scaffolding:

   • Setup all tech systems, infrastructure, and resources

   • Setup the initial project processes and work methodologies

   • Assign areas of responsibility to team members

5. Study the domain and document it

   • Gather required documentation from external dependencies, like APIs or legacy systems

   • Write flow diagrams for the complex journeys

   • Set the project goals (from a tech perspective)

6. Build a coded clickable prototype

   • Start with empty routes. Focus on the navigation first

   • Continue implementing the core journey / happy path

   • Avoid premature optimizations. Focus on simplicity at first

7. Set up the required backend

   • Create a database and a CRUD API (if needed)

   • Implement user authentication (if needed)

   • Systems to handle sensitive details like payment info

8. Deployment and release

   • Setup the staging, pilot, and production environments

   • Setup the CI deployment pipelines and the semantic release process

   • Test releasing to all environments as soon as possible

9. Setup the testing approach

   • Create a testing strategy together with the QA team

   • Have a single source of truth for integration and E2E tests

Once all the previous tasks in both tracks are completed, the project enters a development phase that can last from a few weeks to a few months or even more than a year. It depends on the number of features required to build the MVP. The important part of this phase is to avoid scope creep and drastic changes in the design or the tech architecture. If the initial work was done properly (with enough research and user feedback), there shouldn't be a need to change anything major.

After the MVP

Once the MVP is released into production, the project enters a new phase where the target should be to gather user feedback (from user testing sessions, early users, support tickets, etc) to prioritize the features and changes that need to be done next.

At this point, the team should be very familiar with the domain and the codebase. The focus should be to keep releasing new features, fixing bugs, maintaining the documentation, and optimizing the product quality in general.

Before the official launch

Once the product reaches a certain maturity (after the beta and release candidate versions), the team should be ready to launch an official version. Before launching, it might be necessary to prepare the following:

• An onboarding experience

• A pricing model

• All the legal policies

• Support documentation for end-users (mostly FAQs)

• A process to handle user inquiries

• A process to notify users about changes in the product

• A marketing campaign (website & SM channels) to promote the launch and track its performance

When the product is officially launched, the course of action can vary depending on the company's strategy and the market response. In any case, the team is expected to continue releasing new versions to increase its market fit and user base. Going forward, there are a few considerations to bear in mind:

• Plan large releases into lower-risk well-understood rollouts

• Resolve new issues systematically and rigorously

• Any considerable change in the product should have a design doc or RFC

• Maintain kind and professional communication with your clients and take their feedback seriously

• Remember that you can't please everyone - be extremely mindful when saying "yes" vs "no". Any change request should be taken very objectively. Otherwise, if changes are not well planned, the product IA and UX can be damaged

Sharing the lessons learned

Another usual activity after a product is officially launched is to share the lessons learned with the rest of your organization or even publicly, for example as an article on the company website. This can have several benefits for your audience:

• Understand the challenges your team had to overcome

• Learn which mistakes not to make again

• Discover new techniques, processes, or approaches to doing things

• Attract new talent and increase the SEO

Alternatively, if writing is not your forte, you can always do a workshop, brown bag, or presentation. The goal is the same: to share knowledge, get ideas, and keep improving together.

Conclusions

Building software can be a very intense activity but also highly rewarding, as you can make an impact in people's life. Like any other creative activity, it takes a lot of practice to refine the techniques and processes. But eventually, everyone that has been doing it long enough, starts to understand the patterns and the sensitive areas that need special attention.

Either way, if I had to choose a single aspect that could define the success of a product, I'd say that would be the determination and passion of the individuals on the team. No matter what is the methodology, the technologies, or the resources, if the team is motivated and excited with the product, that energy will overcome any obstacles. Therefore, the advice would be to choose carefully your team and make sure they are truly inspired to make something exceptional.

If you are interested to work in exciting projects, making an impact in the world and you like food, chefs, cool restaurants, and the hospitality world in general, go ahead and check out our careers page. We are looking forward to meeting you!

The following people made contributions to this blog post: Yandis Ying, Tia Pashentsava, Tuesday Gutierrez, Richard McCracken, Wahid Farid, and Calvin Leung.