Introduction
Our client, a company that developed a leading legal software platform, helps consumers and small businesses find answers to everyday legal questions. They provide a range of legal products, primarily to the US market. Included in their offering are "do-it-yourself" (DIY) products. These include legal forms, online documents, and the like. Users fill out an "interview" (a form-based series of pages) then are given a legal product. This product is usually a document such as a will, an LLC application, or divorce proceedings.
The client also operates America's #1 estate planning software, which helps individuals plan their estates. The software helps users create documents like wills, living trusts, healthcare directives, and more.
Problem: Addressing Legacy Limitations
The client’s DIY product software, a legacy web app known as the "form builder", is beginning to show its limitations. It can’t support the complex workflows required by key products, like their estate planning software, which is still stuck as a desktop app. To make things trickier, most of the team members familiar with the form builder are transitioning to other roles, creating a growing knowledge gap that threatens the software’s sustainability. Now at a crossroads, the client needs guidance to decide the best path forward for a long-term solution that meets their needs.
Discovery: The Current State vs Objectives
When we started work with the client, the ask was to figure out what to do with the software powering their DIY products. To learn more about the situation, we decided to start with a discovery. Performing this discovery would allow us to understand the true nature of the existing software, and give the client better advice on how best to proceed.
The software was a mature web application written in Groovy. There weren't many people in the organization who knew how to maintain it. Those who did were moving to other roles. The client called this type of software a "form builder".
The existing software lacked features that prevented it from powering more complex products. A sore point was that it couldn't support their estate planning software's complex interview workflows. Their estate planning software was only available as a desktop application - the client wanted to bring it to the web.
The client's objectives were:
- Establish a long-term technical solution for DIY products.
- Use this solution to create a web-based version of their estate planning software.
What to do with the existing form-builder solution was also a concern. Should we:
- keep it, learn how to maintain it then extend it to support their estate planning software?
- replace it with an off-the-shelf alternative?
- replace it with a platform that we build ourselves?
The choice we'd make here would determine the service we'd perform next. Keeping the existing solution would mean a Legacy Application Modernization. Replacing it with an off-the-shelf alternative would mean helping the client with a migration. Building ourselves would mean a Brownfield Development project.
Planning: Getting The Foundations Right From The Start
We were to help the client answer the above questions, then help them implement the chosen solution. This was to be a long-term relationship.
We also understood that there were many stakeholders within the client organization interested in the outcome of this project. A form builder capable of powering their estate planning software was a potential game-changer. It would have implications beyond just this product.
So we didn't jump in and start coding right away. Instead, we felt it important to establish a framework to keep us grounded as we made progress. Something suitable for the situation surrounding the work we would be doing.
First, we decided to use Scrum to organize our team and our work. The cadence of fixed-length Sprints would provide regular progress in predictable increments. Sprint Reviews would provide a time for stakeholders to learn about project developments.
We were a remote team and we were remote from the client (who are based on the US Pacific Coast). So we made written communication central to how we operated. First we created a central document to be the go-to place for information about the project. This detailed the following:
- A project charter, outlining the high-level purpose of the project and the current state.
- Who the team members were and their contact details.
- Who the primary stakeholders were.
- Where the project roadmap, product backlog, and Sprint board were.
- Links to artifacts we produced, like research documents or recorded presentations.
We would send anyone interested in the project to this document. This would allow them to learn and discover about it on their own. If someone had a question that the document didn't cover, we'd provide an answer by way of updating the document.
Our initial team was two Software Engineers (SE) and one part-time Product Manager (PM). The PM assumed the role of Product Owner on the Scrum team and one of the SEs assumed the role of Scrum Master.
At this point, we were well grounded and ready to get stuck in.
Implementation: Building a Scalable Online Estate Planning Platform
Solutions Evaluation: 3 Possible Approaches
Our first goal was to decide what to do with the existing form builder. We considered each question in the list above in turn.
Option 1: Keep it?
We decided to evaluate the effort needed to modernize the existing solution. To do this, we spent some time contributing to it. We fixed some open bugs, improved a few features, and learned how to deploy the application.
It became clear that keeping the solution was a no-go. The original creators of the software had chosen Groovy as the implementation language. At the time Groovy was a promising new technology. But it hadn't stood the test of time. It had become a niche language with a marginal ecosystem to support it. Language updates and supporting libraries were sparse and couldn't be relied on.
The application itself needed major upgrades. The architecture of the code wasn't able to support the features we needed to build their estate planning software. And the admin user experience hindered their product editors from working efficiently. The case to keep the existing solution was non-existent.
Option 2: Off-the-shelf alternative?
Our next question was: could we replace it with an off-the-shelf alternative?
This was a fair question. We were talking about a software application that was generic in nature. It was a form builder, and there are many form builders on the market. Could we find one to suit our needs?
The process we followed to find a suitable candidate was:
- Create a shortlist of possibilities.
- Do a quick "surface level" evaluation each to gauge suitability.
- Identify the most promising candidate.
- Build a proof of concept (POC) with the most promising candidate.
If our first choice turned out to be unsuitable, we'd consider building a POC of the second candidate.
We compared six candidates and decided that the most promising was one based on SurveyJS.
We built a POC of the form builder using SurveyJS but found it unsuitable. The features needed for their estate planning software were much more complicated than what SurveyJS offered. We would have to significantly extend SurveyJS - something we didn't think was sensible. No other candidate came close to SurveyJS, so we decided not to try another. We had, in essence, concluded that an off-the-shelf solution was a no-go.
Option 3: Build ourselves?
Having eliminated the other options, we decided to write the form builder ourselves. The engagement had become a Brownfield Development project. But we weren't ready to leave evaluation mode just yet. We had to determine the stack we would use.
Users would navigate a series of forms, oftentimes on their mobile devices. So we decided to build a single-page application (SPA) with a mobile-first design. We based the frontend stack on React to help us keep a complex user interface organized.
When it comes to backend development, one of the proposed approach was to use Ruby on Rails. This wasn't appealing to the client as their other applications are mostly written in PHP. So for the backend, we decided to use Laravel. Laravel is an MVC framework for PHP which is much like Rails, so we felt comfortable using it. We chose GraphQL as the basis of our API, as we expected large, nested payloads to come in from the frontend.
With the technical direction set and our tech stack chosen, we started implementation.
Establishing the New Forms Platform: Coordinating Workflows and Launching the First Product
As we got started, we had to take note of and coordinate with several adjacent teams within the client organization.
The full application was more complicated than just a form builder. The major user workflow when using DIY products was:
- Complete an "interview" (via forms from the form builder) to gather necessary information.
- Receive a "document", based on the information gathered from the interview.
So our application had to support both the interview workflow and document generation. The interview would come from the form builder. The document generation hadn't been deeply considered.
On top of this, non-technical admin users were to create the interviews. These were legal experts who knew what information to collect for each product. We needed an admin interface to design interviews and manage products.
The client's design team created the UI/UX designs for us. They were in the form of hi-fi mockups created in Figma. These designs were not all created upfront. The initial parts of the application were designed based on what we were going to work on first. As the project progressed the design team supplied us with further designs as we needed them.
We knew upfront that the interview workflow was the highest priority piece. But given that non-technical users would use the admin tool, we constrained our approach. Config files would be used to define all interviews. Such config files would be passed to the frontend and used to render the interview forms. If the frontend worked in this way then we could build an admin tool to generate this config later.
Our goal during this phase was to implement a simple product from the client's catalog. We chose their promissory note product.
Shifting Focus: Building a Strategic Online Estate Planning Solution
As the new forms builder started taking shape, project objectives were oriented to their estate planning software. Up until this point, our major driver was: "we are building a forms platform". But the major prize from a business standpoint was having an online version of their estate planning software. We decided to change our major driver to: "we are building the online estate planning software".
But why do this? Their desktop estate planning software is a good product. It supports all the use cases needed for estate planning and has been successful for decades. Why build an online version of it?
The answer wasn't to do with functionality. There weren't features missing from the desktop version that only an online implementation could provide. Rather, it was strategic advantages that were driving us. The online estate planning software would enable
- different payment options, including subscriptions
- access on mobile devices
- bundling with other legal products
- all users getting new features as soon as they're released
Our goal wasn't to cannibalize Desktop per se. It was to make a complementary product that would take advantage of these strategic options down the road.
Defining the MVP: Building Essential Features for Estate Planning Software
When carrying out a Brownfield project, we build a new product to replace an existing one. The first step is to build a Minimum Viable Product (MVP). The scope of the MVP is inspired by the existing product, oftentimes by the most pressing existing pain points. As work on the new forms platform progressed, we were gradually honing in on the scope of our MVP.
The overarching goal was for the MVP to provide estate planning products. But we needed a strategy by which to approach the estate planning implementation. We figured that knowing that the platform had all the necessary features was the first step. Once we knew that, we could build the full solution later. So we began prioritizing the features that the estate planning software needed.
The estate planning software allows its customers to produce several legal documents. These include:
- Wills
- Living Trusts
- Healthcare Directives
- Durable Power of Attorney for Finances
- Letters to Survivors
- Transfer on Death Deeds
To build the estate planning software is to build all these "standalone" products, then bundle them as one package. We chose to focus on the Will first. This was because the Will needed many of the features the other products needed too.
“Mini” Will: A Turning Point for the Estate Planning Software
But even taking on the Will was a major chunk of work. We wanted to set ourselves a goal that was achievable in a shorter time frame, so we decided to implement a "Mini” Will.
We set the scope of the Mini Will according to three principles:
- It must use all the platform features that the Will would use.
- It must not make repetitive use of such platform features.
- It should show a coherent experience of creating a Will.
The first point ensured we could create the (Full) Will in a later iteration. The second point allowed us to complete the Mini Will with as small a scope as possible. The third point would let stakeholders see what the platform was capable of.
We went on to build the Mini Will. The platform proved capable, and we showed stakeholders that it had the ability to create a Will. This was an important moment. Up until this point, there was some doubt that creating the estate planning software on a form builder was possible. When we demonstrated the Mini Will these doubts disappeared. It was a turning point, where consensus went from "can we do this?" to "we're doing this!".
Defining the Roadmap: Online Estate Planning Software
The turning point was, in fact, more fundamental. It became a widespread desire to ship the online estate planning software. The question on everyone's lips was: when can we launch?
We are always careful when making estimates. The future is uncertain, and we don't like to accidentally provide inaccurate information. Doing so can cause others to make plans which rely on such information becoming true.
So instead of giving a direct answer to the question, we took a different approach. We made as much information about the project available as possible. Then we shared different timelines based on choices we could make about the project scope.
We shared this through a project roadmap. We continually kept this roadmap up to date. This made sure that the latest information was available to everyone interested.
The roadmap helped us with some strategic aspects of the project:
- Seeing that building the online estate planning software was to build several standalone DIY "form" products.
- Estimating forms we hadn't started could be done quite accurately. Estimates of forms we'd already completed provided a good yardstick.
- We started seeing where the gaps in our thinking were. Included in this were the interface points with other systems at the client organization. We could figure out what we needed from other teams - teams that managed the systems we would interface with.
- We plotted a course to launch the online estate planning software. This would later include deciding to build some features after launch.
Scaling the Team for the Next Phase
When we decided to go all out on pursuing the online estate planning software, we expanded our team. We grew to four SEs and one dedicated (full-time) PM.
To counter this shift, the SEs on our team took on the work to create technical tasks for our backlog. This meant our PM could focus on user story creation. Our Product Backlog was always sufficiently populated ahead of Grooming and Sprint Planning.
Validating Technical Capabilities: The Living Trust
The second form in the estate planning software suite is the Living Trust. The Living Trust's interview isn't as complicated as the Will's. But another factor made its technical implementation the most challenging of them all.
The interview logic had to be accessible to users in different "modes''. First, the trust is created (via creation mode). Later it can be amended (amendment mode) or restated (restatement mode). It can also be revoked (revokement mode). Completing the interview in these different modes produces different documents. Each mode also changes the interview in subtle ways.
Stakeholders felt that if we could support the Living Trust, the platform could do anything. Within our team, we had been confident we could implement it from the start.
With time we built the major technical aspects of the Living Trust. Remaining skepticism of the fitness of the platform evaporated. Now it was time to put our heads down and get to launch.
Verification: A Phased Approach to Launch and Scope Flexibility
An Interim Launch: The Full Online Will
At this stage, we focused on building the complete set of forms for the online estate planning software. Instead of opting for a "big bang" release of the entire suite, we decided on a phased approach. Releasing an initial, smaller product increment would allow us to:
- Verify real customer interest and willingness to pay for the product.
- Complete essential "plumbing" work by integrating with other services to prepare for launch.
By launching an initial feature, we could address unforeseen obstacles early, minimizing risks for the full release. Our selected first release was the Will form, known as the "Full Online Will.”
To launch the Full Online Will, we integrated it with the client’s storefront, creating a dedicated product page to guide customers through the purchase flow. We also connected the Will form to the client’s payment system. During this process, we encountered and resolved several unexpected technical issues, gaining valuable insights that would ease the larger estate planning software launch.
Setting a Target Launch Date and Flexing the Scope
At this point, we had completed the Will form, made progress on the Living Trust form, and started groundwork for the Healthcare Directive. However, three additional forms remained unfinished.
There was mounting pressure to set a launch date. Collectively, we wanted to bring customers on board and plan marketing activities. But the remaining scope of work remained substantial and it wasn't feasible to lock in a target date yet. This situation started to cause some tension between stakeholders. What to do?
At the center of the discussion was a desire for something impossible. To set a launch date (six to nine months out), and implement the full scope of the online estate planning software in that timeframe.
The reality of the situation was that we could have one but not both. Either we set a launch date and flex scope to meet it, or fix the scope and accept a longer-term, non-determined date.
We advocated for flexing the scope of the product. We wanted to achieve Earliest Usable Product. We identified what parts of estate planning software could be released after the initial launch. We also nominated dedicated QA and UAT representatives for the project. These representatives joined our team and enabled a tight testing loop.
We decided what to defer by considering the existing product's user metrics. We chose to launch in only some US states, rather than all. We identified which states by examining a selection of user and traffic data. We applied the 80/20 Rule. We realized that by focusing on only 10 states we could reach 55% of existing user locations.
Having the roadmap was instrumental at this stage. It helped us visualize our decisions, and communicate when the remaining features would launch. It helped us agree on a timeline that was reflective of the team's velocity and the client's business strategy.
We established a "fast follow" process to release the deferred features. These features were organized in order of priority into numbered batches (or versions). We placed fast follow batches into sprints succeeding the launch. This was reflected on the roadmap.
Handoff & Empowerment: Final Launch Preparations
Building the Consumer Portal with a Second Team
As the forms of online estate planning software were progressing, a looming reality was emerging. Some supporting services had to be built to make the software complete. These services went beyond what the Full Online Will had covered. Until this point, they had taken a back seat in our planning.
Among these was the Consumer Portal, designed to guide users from landing through signup, payment, and accessing forms. Unlike the client’s existing workflows for other DIY products, this estate planning suite required a tailored, immersive experience.
To stay on track with form development, we brought in a second Hivekind team dedicated to building the Consumer Portal. This team’s objectives were to:
- Develop the Consumer Portal.
- Integrate it seamlessly with the estate planning software.
- Perform any other support work needed for a successful launch.
This increase in capacity allowed us to bring Consumer Portal fully onto our roadmap. We could give it a reasonable estimate and timeframe. We remained on track to our target launch date.
Launching the Online Estate Planning Software
Our launch scope was clear, with planned features and fast-follow updates fully defined. Supporting services like the Consumer Portal were being developed and integrated alongside form work, keeping us on track. Thanks to thorough planning and a steady sprint cadence, our engineering teams maintained consistent progress.
When our launch date came around we were ready. We had completed the features that were in scope. We used a feature toggle to direct 5% of their traffic to the Online experience.
This was a huge win for us, and to mark the occasion we went out to celebrate:
Party time after the launch
Post-Engagement Support: Product Evolution After Launch
The launch wasn’t the end of our journey with the client, it was just the beginning. Beyond the initial rollout and "fast-follow" features, the client had ambitious plans to further expand the online estate planning software and develop additional products on the forms platform.
Estate planning was just one of many services the client provided, and we soon started exploring new products that could leverage the platform’s capabilities. With a clear understanding of the strategic goals behind the online estate planning software, we helped the client begin planning for future initiatives within the agreed post-engagement support.
Conclusion: Achieving Objectives and Setting the Stage for Future Growth
Following the launch, the rollout rapidly scaled. Within three months, the online estate planning software was available in all 50 U.S. states. Six months post-launch, 100% of users were directed to the online version. By this point, the client was also offering bundled packages, allowing customers to choose between Online-only or Online + Desktop options, further expanding the product's reach and accessibility.
Through these efforts, we successfully met the objectives defined in the discovery phase:
- Establish a long-term technical solution for DIY products.
- Create a web-based version of the estate planning software.
These achievements underscore the successful partnership in advancing the client’s mission, effectively setting the foundation for future growth and innovation in their DIY offerings.
