One-week cycles, big gains: MVP development done right

On a mission to build an internal tool for a client. Fast.

Tome is a legal tech startup based in California. Their product is an application that summarizes contracts using AI and Large Language Models. They specialize in investment contracts. If you're a Tome user, you can upload your contract, and within minutes, you'll receive a summary, highlighting non-standard sections. If anything is non-standard, a Tome team lawyer will review it within a few hours and provide an explanation.

The Tome ecosystem consists of microservices that play a key role in processing and evaluating individual contracts. There's also a customer-facing app for users to view summaries of their contracts. Lastly, there are various small applications in Retool, a no-code tool for building internal apps, mainly used by developers for visualizing their backend.

However, the ecosystem lacked a tool for lawyers to view, review, and perform additional operations on contracts themselves. This led to the development of an internal back-office tool for the legal team, fulfilling Tome's request.

Initial requirements:

• An internal tool with the defined type of user

• Rapid delivery approach with good code quality

• Focus on the UX of the provided solution and performance

Involve stakeholders and the engineering team early on

To summarize, our collaboration with Tome began with a two-week product discovery phase. If you are not 100% sure what I mean by product discovery, check our article by our CPO.

During the discovery phase, we engaged engineers, lawyers, and the CEO to understand their workflow and expectations for the internal review tool. This phase, led primarily by the product manager with my technical lead involvement, laid the groundwork for defining the MVP.

The subsequent phase involved four-week development cycles aimed at delivering the MVP for internal review, where the client needed a tangible product. Our team initially consisted of a product designer, followed by two senior developers and one junior developer.

Importantly, this four-week period paved the way for a longer-term partnership, as long as both parties continued to collaborate effectively. It's worth noting that our collaboration eventually extended to a full year, and many of the practices I'll present were applied throughout the entire period.

Our cookbook of fast delivery

As we move forward, let's take a look at the practices that we have implemented.

1. Short cycles with frequent releases and instant feedback

One of the key factors in successful and efficient collaboration, in my view, is very short cycles during which we:

1. Presented new features to the client.

2. Received feedback and requests for further features/changes.

3. Implemented the feedback and added desired features.

4. Deployed a new version.

5. Showed the client the updates again.

This entire cycle took one week. In the context of MVP, getting feedback ASAP is crucial; I believe any extra time is a waste.

We demonstrated features even when they weren't 100% complete, deploying them to the development environment and, likewise, deploying them to production with some unfinished features hidden behind feature flags.

Thanks to regular and frequent releases and demos, we received instant client feedback. This kept the team motivated and informed about the client's feedback, while the client felt a constant sense of progress. We applied this principle throughout the entire collaboration, not just in the initial phase.

2. The presence of the tech team in the product discovery

Another crucial step toward our success was having developers actively involved in the product discovery phase. During the initial discovery stage, I, as the tech lead, played a pivotal role. This helped me gain a deeper understanding of the product and allowed me to convey technical challenges to the developers right from the beginning.

As time went on, we conducted more meetings, particularly focused on new features, in the form of product calls where developers actively participated. This significantly improved our comprehension of what and, most importantly, why we needed to work on specific tasks.

One of the most common product meetings was actually the demo itself, attended by all developers. This provided us with the opportunity to react to client requirements and ask more questions.

Because of the presence of engineers on discovery and product-related calls, there wasn't a significant need for extensive knowledge transfer between the product manager and the development team, and technical questions could often be addressed during the meetings themselves.

3. Let the engineers be creative

This part happens to be my favorite because it showcases the untapped potential of developers. Developers are individuals who work with various tools, understand different UX patterns even if they can't name them, and appreciate when things run smoothly. It's a shame not to harness the potential of this knowledge.

In my view, it's crucial to explain to engineers WHY a particular feature is being developed; only then can we gain their valuable product perspective. In our case, the significant win came from their active involvement in discovery and demo calls, as it spurred the development team into more proactive action.

Nevertheless, a huge shoutout goes to our designers and product managers who provided us with the space for creativity and didn't extinguish our ideas.

I personally believe that regardless of rapid development, there should be a degree of flexibility in tasks, allowing developers to make decisions about solutions or propose their own ideas.

I also have real-life examples, as I consider this aspect crucial not only for delivery speed but especially for the overall product value:

#1 Real example

An example of this was a request to prepare a user interface that would allow users to restructure the document by joining and splitting different parts of the text segments. However, the sole motivation was to provide users with a temporarily unified portion of text to work with further.

After the client explained their request, we, as engineers, pondered whether there might be a more straightforward and better approach to tackle the problem.

Upon brief reflection, it became clear to us that it would be sufficient to make actions on text selection. Based on the highlighted text, we could enable further operations, as these text segments were meant to be temporary.

When estimating this feature, this approach turned out to be nearly half as time-consuming, and the lawyers themselves ended up loving the feature. This example illustrates how, with engineering input, we were able to deliver a feature more quickly with a better user experience.

Another example was the display of document differences (diff). The requirement was to show a GitHub-style diff between a user-uploaded document and a selected standard contract. This presented a complex challenge, requiring multiple iterations involving design, product, development, and the client.

Here, the power of engineering knowledge in using various tools became evident. As developers accustomed to reviewing code diffs daily, we were able to propose enhancements crucial for reviewing document differences. For instance, we suggested splitting texts into sentences and meaningful sections separated by commas, semicolons, and so on.

This example illustrates how our insights contributed to a higher-quality end result, likely saving a series of client feedback iterations and implementations in the process.

4. Adjust the design to the existing UI library

Many times, during projects, I've had design assets from a designer, and if I wanted to use a UI library, it could be quite challenging. This is a well-known downside of UI libraries.

However, since our focus was on rapid delivery for an internal tool, using a UI library like Chakra UI was justified. We adapted the design to fit the UI library, although the designer wasn't always thrilled. Nevertheless, there's still the option to iteratively modify certain UI elements over time if they don't meet the requirements.

For example, in our design, we see several UI elements that align with Chakra UI components, such as tooltips or badges. The tooltip, for instance, was originally conceived differently, but we used the Chakra UI tooltip that we had readily available out of the box.

5. No technical experiments

It's probably not so surprising that in a project where rapid development is the goal, there won't be a lot of room for technical experiments. In our case, we stuck with a stack we were familiar with:

• NextJS, Typescript, Chakra UI

• Postgres, Apollo GraphQL

We also used our company's project template, which is employed across multiple projects within the company. Essentially, when you're working on a tight schedule like we were during those four weeks, setting up the project should be a routine process that doesn't require too much manual consideration.

6. Optimize process, not code

If there's something to optimize, it shouldn't always be the code itself. Responsible code performance is essential, but I strongly recommend avoiding optimization until it's necessary. In the context of rapid delivery, process optimization has far more advocates, especially in the case of automation.

Having fully automated deployment saves time with every release, occurring once a week, for instance. In your CI/CD pipeline, as many automated checks as possible for code quality and testing should be running.

If you notice recurring issues in code reviews, try to automate as much as possible, perhaps through ESLint rules or other automated tools. This not only accelerates the development process but also enhances code quality and consistency.

7. Invest time wisely

Time is a precious commodity that should be invested wisely. In the initial phase, we skipped many ceremonies, such as planning, grooming, and even temporarily retrospectives, retaining only daily standups.

Personally, I believe that time spent on product meetings is highly productive time. It's an investment that pays off in solution quality and time saved on knowledge transfer. In our case, grooming and planning weren't necessary, as the plan was adjusted after the demo.

I wouldn't hesitate to prioritize time investment in:

• Common Code Review Sessions: Particularly for substantial changes, this can save time. The pull request author can walk through the most significant changes, explain why they were made, and address any questions.

• Product Brainstorming: This can be approached from a technical perspective, providing valuable insights into potential solutions.

• Pair Programming: While I used to view it as a waste of time, I've since learned to work efficiently with it. It has proven beneficial, especially for more complex tasks.

Investing time in these activities can yield significant returns in terms of quality, productivity, and collaboration.

No approach is without its challenges

Indeed, as with most things in life, no approach is without its challenges, and this one is no exception. Here are some of the issues that can arise from the various points discussed:

• Accumulating Technical Debt

  Rapidly adding features without adequate code review and refactoring can lead to technical debt. The solution is to implement a "cool-down cycle" where the focus shifts from adding new features to cleaning up and refactoring the codebase to improve its quality and maintainability.

• Stagnation and Technology Familiarity

  Continuously using the same technology stack can lead to a feeling of stagnation among the development team. This can be addressed by engaging in side projects that involve new technologies, providing learning opportunities, and investing time in self-improvement.

• Client Expectations

  As the codebase grows, it becomes challenging to maintain the initial rapid pace, which can lead to changing client expectations. Effective communication and setting realistic expectations with the client are key to managing this challenge.

In essence, open and transparent communication, coupled with proactive measures like cool-down cycles, side projects, and ongoing learning opportunities, can help address these challenges and keep the development process on track, even in a rapid development environment.

A high level of trust required

Despite the downsides, our approach allowed us to deliver a working MVP in just a few weeks and keep the client happy. However, it's important to note that this approach may not work for every project or team. It requires a high level of trust and collaboration between the client and the development team and may not be suitable for projects with strict deadlines or complex technical requirements. Client trust in the development team is essential for maintaining motivation and creativity within the engineering process.

The strategy described was applied successfully over the course of one year, resulting in valuable feedback, improved communication, and consistent client engagement.

When is this approach suitable?

It is most suitable when facing tight time constraints and the need to showcase progress iteratively. It's crucial for the client to accept the iterative nature of development, with the understanding that features may start as partial solutions and evolve over time.

Tome initially had a simple functionality that was continuously enriched, making the absence of a detailed roadmap less of an issue. However, for significantly more complex projects, spending more time on analysis and establishing solid foundations would be advisable.

This rapid approach can have a significant impact, particularly for internal applications, although the principles can be applied to customer-facing apps as well. In your case, even occasional bugs stemming from rapid development did not hinder overall success, but in different scenarios, investing more time in testing may be necessary.

If you've got an idea you'd like to discuss and you need a ready-to-go & dedicated team of product managers, designers, and engineers, we are ready to help. Drop us a line at [email protected] or book a call with our CEO, Jozef.