← All work

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

Collectors take a card payment at the counter by choosing Swiper on the tax notice and pressing Swipe Card.

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.

  1. 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 out

    Pausing support until a new contract model was settled.

  2. 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 out

    An informal handover held only in people's heads.

  3. 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 out

    Leaving the code outside the owner's accounts while we kept shipping.

  4. 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 out

    Running our work as a separate track outside the owner's process.

  5. 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 out

    A separate support desk that learns each office from tickets.

How the system fits together

plans sprintsshared taskscommitscommitsreleasesper officereversal webhookdaily workOwner's productownersPlan sprints, ownthe roadmapOther developersThe owner's own andanother vendor'sOwner'sengineering spaceSprints and sharedtasksOwner's GitHubHolds the sourcerepositoriesFeatures andfixes we shipSwipers, ACHreversals,…QA per officeA separateenvironment…NMI paymentgatewayCard and ACH, aprocessor per officeProduction perofficeWhere officescollect every dayTax office staffCollect, balance,close the month
PeopleClient's existing systemBuilt by DaticsOutside serviceThe code lives in the owner's GitHub, and each office runs on its own QA and production environments on AWS.

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.

Balancers post a refund check from the record details screen with the check date, number, payee and reason.
02

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.

03

ACH reversal handling

A webhook from the NMI gateway handles ACH reversals, next to new reversal and protest tax reports for each office.

04

Calculation fixes

Redemption, refund, adjudication and supplement calculations corrected in a product offices use every day, checked against the money flows they feed.

05

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

Each tax office has its own entry point on the shared platform.
Each tax office has its own entry point on the shared platform.

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

PostgreSQL

Cloud and infrastructure

DockerAWS

Apps and APIs

PythonDjangoReact

Also in the stack

GitHubNMI payment gateway

How it shipped

  1. 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.

  2. 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.

  3. 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.

  4. No pause for the move

    Feature sprints carried on right after the code moved, adding payment and sale features while every office kept collecting.

  5. 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.

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.

Book a 30-minute Product Review