Guidr
Guidr enables law firms to quickly enter the market and reach new customers via an online process. The customer selects a particular document and goes through a dynamically changing interview. After finishing, interview answers are reviewed by an attorney. When the review is finished, printable documents are rendered from templates.
Team and Project Setup
After initial talks and discovery, we have prepared a detailed roadmap highlighting important features to be delivered. We quickly adapted to an investor's demand where design and important frontend components would be designed by a third-party supplier. Over the course of the whole project, we have had a principal engineer overseeing the project and ensuring that the investor needs are being addressed.
When we were near MVP and approaching live production, we focused more on stability and quality. Therefore engineering was reduced in favour of the QA. During the whole lifecycle of the project, the PureBrew team regularly and intensively collaborated with investors, business stakeholders and other suppliers, while being in charge of short-term planning and scheduling of tasks. The team was working in a fully remote setup and we were able to quickly onboard multiple external members as per investors' needs.
Architecture
Guidr is built on top of state-of-the-art cloud infrastructure. Critical parts of the platform, like authentication, are relying on proven cloud solutions.
-
Core 1
Guidr consists of a single-page application, enabling a rich experience while interacting with the application. The backend is split into multiple independent microservices, each of which has clearly stated boundaries. Microservices interact with each other via events that enable us to control and maintain complex configurations for error handling and retries.
-
Core 2
We have implemented independent services to integrate with multiple third-party systems of workflow management, calendars and document management. A robust document rendering engine was implemented according to the investor's needs. Over time the service and its implementation evolved into a full-featured product for document rendering on its own.
-
Monitoring and alerting
An important part of the project is monitoring. This was set up and built in the early stages of the project, giving the team a robust toolset to quickly discover and understand problems the platform might experience. The monitoring must include both the frontend and backend by using the correct tools. These are capturing events from the whole stack.
-
Quality Assurance & Documentation
At PureBrew, we strongly believe in testing. Since the early stages of the project we were developing complex test suits that validate business requirements and assumptions.
-
Backend
On the backend, we maintain a rich collection of scenario-based tests that test the platform from the API layer perspective. Having the infrastructure in place as well as having a custom DSL to ease developer UX prove very useful while adding new scenarios to support new features or discover problems. Interview completion and translation of the data to the rendering engine are tested via randomised ScalaCheck tests. Within this suite, we make sure that we are able to render each individual document with a broad set of randomised input values. The solid design of ScalaCheck suites allowed us to test new documents for free without any changes to the suite.
-
Frontend
Another layer of testing is complex scenario-based tests from a frontend perspective. We have implemented a set of tests in Playwright that simulate real interaction with the platform covering the whole functionality. Mocks are used minimally and we try to test the system in as real a setup as possible.
-
User scenarios
Just automated tests are not enough to catch all errors. We have therefore recommended and introduced another layer of testing - user scenarios. This is a complex set of user scenarios testing various features of the platform to be executed by a QA person. Not only did this help us discover some hidden bugs, but it also serves as a very useful knowledge base capturing the requirements and features in a structured way within Xray and Confluence. These scenarios are being re-executed as needed.
-
Challenges
We have implemented various eDSLs to describe and configure complex parts of the system.
-
Lifecycle and ACL to the Interview
The interview is stepping through multiple steps, in which user, as well as superuser actions, are restricted or completely forbidden. All actions are also being audited in order to satisfy regulatory needs.
-
Inverview Configuration
Interview questions and possible answers change dynamically based on the already supplied answers, law firm configuration and user configuration. We tackled the rapidly increasing complexity of the configuration by carefully designing an eDSL that concisely describes it.
-
Transformation of the Answers
While the interview is being kept quite simple for end-user convenience, the documents rendered are quite complex. The platform, therefore, performs various transformations to the interview answers and they are passed to the template only after the transformations are performed. Typed functional programming language proved to be the ideal fit for the task, and we were able to develop a robust eDSL for the description of the transformations while still being able to alter and extend it quickly as new business needs were coming.
-
Rendering
In order to integrate with existing business processes we have developed a complex parser and render engine for templates. This stands as a standalone service, which greatly simplified the architecture of the system. Main backend services interact with render service via an asynchronous queue.
