Government payments software company
Tax offices kept collecting while our engineers moved into the new owner's team
When a government payments software company took over a live property tax platform, we kept every tax office collecting through the handover. Then our engineers moved inside its team: its GitHub, its sprints, next to its own developers and another vendor.
Government, Legal & DefenseProperty tax collection platformModernized a live product
The challenge
A live tax platform changed hands while offices depended on it every day. The new owner needed it running everywhere while it took over the code and the roadmap.
What we did
We kept production support first, proposed a written transition plan, moved the repositories into the owner's GitHub and joined its team and sprints.
The outcome
Offices kept collecting through the change of owner. The owner holds the code and runs the roadmap, and features keep shipping in its sprints.
- Collection
- Kept running through the change of owner
- Handover
- Code moved to the new owner's GitHub
- Cadence
- Two week sprints in the owner's engineering space
- Team
- Owner's developers, another vendor and our engineers
The starting point
A multi-tenant property tax platform that sheriffs' tax offices use every day to collect, balance and disburse property tax. It was already in production for several offices when the product changed hands.
What had to change
The new owner needed the platform kept running while it took control of the code and the roadmap. It also wanted to keep adding features with its own developers and another vendor in the same codebase.
What could not break
- Collection, batches and month close keep running at every office
- Change orders, lockbox and mortgage files, redemptions and disbursements keep flowing during the handover
- Tax season and tax sale dates do not move for a change of owner
- Changes from three teams still have to balance batches, checks and month close
The calls we made
We treated the handover as part of production support: keep every office steady first, then move ownership in steps the new owner could check, then work as part of its team.
- 01
Production before restructuring
Offices depended on the platform every day, so change orders, lockbox and mortgage files, redemptions and disbursements stayed ahead of any reorganization, and demo sites for two prospective offices went up alongside them.
Ruled outPausing support until a new contract model was settled.
- 02
Hand over knowledge in writing
We sent the SRS for the owner's documentation request and proposed a transition plan: name a product owner and a technical lead, run knowledge transfer sessions with documentation, and choose a shared team or added engineers.
Ruled outAn informal handover held only in people's heads.
- 03
Move the code to the owner
At the owner's request the source repositories moved into its GitHub, so it holds the code and every later change goes through its own process.
Ruled outLeaving the code outside the owner's accounts while we kept shipping.
- 04
Join the owner's team, not run beside it
Our engineers plan work in the owner's engineering space with its product owners, and shared tasks carry its developers and another vendor's as assignees.
Ruled outRunning our work as a separate track outside the owner's process.
- 05
Production support and features in one team
The same engineers who ship features also handle change order, payment file and redemption work for each office, so nothing waits for a hand off between teams.
Ruled outA separate support desk that learns each office from tickets.
How the system fits together
What we built
Batch and refund controls
Reopening a settled batch before month close, multi void and reprint, a mass void of refund checks to one entity, and manual link and unlink of redemptions.
Card swipers for every office
In office card swipers rolled out to every office, so collectors take card payments at the counter inside the office system.
ACH reversal handling
A webhook from the NMI gateway handles ACH reversals, next to new reversal and protest tax reports for each office.
Calculation fixes
Redemption, refund, adjudication and supplement calculations corrected in a product offices use every day, checked against the money flows they feed.
Letter templates
A letter template editor with dynamic variables and PDF generation, a view to manage and create templates, and default templates for every existing letter.
How it works
Plan with the owner
Work is planned in the owner's engineering space, with its product owners on the tasks.
Pick up the shared task
Our engineers take the task in the owner's space, where its product owners, its developers and another vendor's developers work the same board.
Build in their repositories
We commit to the owner's GitHub alongside its own developers and another vendor.
Test the money flows
Test case suites and a regression sheet cover payments, batches and month close.
Release office by office
Changes reach each office through its own QA and production environments.
A closer look
What changed
Every office kept collecting through the change of owner while we handled its production work. The owner now holds the code in its own GitHub and runs the roadmap, and our engineers keep shipping in its sprints next to its own developers.
Under the hood
- Datics role
- Forward deployed engineering
- Code ownership
- Repositories live in the owner's GitHub organization, with deployment steps documented.
- Environments
- Each office has its own QA and production environment, so a change from any of the three teams is checked office by office before it reaches collectors.
Data and retrieval
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Keep every office running
When the product changed hands we kept supporting every office: change orders, lockbox and mortgage files, redemptions, disbursements and demo sites for two prospective offices.
Transition plan
We handed over the SRS, met the owner's team on next steps and proposed a plan with a named product owner, a technical lead and knowledge transfer sessions.
Code into the owner's GitHub
At the owner's request the source repositories moved into its GitHub organization, so every later change runs through its own process.
No pause for the move
Feature sprints carried on right after the code moved, adding payment and sale features while every office kept collecting.
Sprints in the owner's engineering space
Two week sprints, planned with the owner's product owners: card swipers for every office, ACH reversal handling, calculation fixes and letter templates.
Their repositories, their sprints
Our engineers work in the owner's GitHub and sprint process, with its product owners, its developers and another vendor's developers on shared tasks.
Production support through each season
Production work, from change order and payment files to redemptions and distribution checks, ran alongside new feature work through each tax season.
A plan the owner could act on
Our transition plan asked the owner to name a product owner and a technical lead and to choose a shared team or added engineers, and our engineers now work inside that team.
What this unlocked
Letter templates with dynamic variables are in the current sprint, with faster tax roll loading per office, full module regression and general ledger integration on the owner's list.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.
