The workflow before#
Praxis Rock Advisors runs fundraising and investor outreach for the firms it works with, so its investor database is the business. That database lived across a stack of no-code tools stitched together over time. The rules that mattered most, such as how tags carried from one record to another, how blocklists applied and which system won when two disagreed, were buried in tool settings and written down nowhere. As the database grew, syncs broke without warning. Every import brought in new duplicates that someone had to find and clean up by hand. And the setup couldn't meet the security expectations of the firms whose investor relationships Praxis Rock was trusted to manage.
What we built#
We replaced the no-code stack with an application built around how Praxis Rock actually raises capital. Before writing any code, we pulled every hidden rule out of the old tools and wrote it down. Those rules are now tested code, the investor database has one home, and bad records are stopped on the way in instead of cleaned up afterward.
A rulebook pulled from the tools
We ran workshops with the Praxis Rock team to inventory every piece of business logic hidden in the no-code tools: tag propagation, blocklist precedence and sync direction. That inventory became the specification. We did this first because the old setup's real behavior was the only true record of how the business worked, and rebuilding without it would have meant losing rules nobody remembered setting.
One app for the fundraising workflow
The team works in a custom web application shaped around its fundraising process, backed by a single PostgreSQL database as the system of record. The rules that used to live in tool settings are now Python code with tests, so a change to how blocklists apply is reviewed and tested before it touches a live investor list.
Bad data stopped at the door
Every import runs through validation and deduplication before anything is written, and the database enforces uniqueness on its own. We put governance at the data layer rather than in the screens, so no import path, script or user can slip a duplicate past it. That's what takes manual cleanup off the team's plate.
Access by role
Only authorized users can import or update investor data, and access is set by role. Praxis Rock can now show the firms it works for exactly who can touch their investor relationships.
How we delivered it
Discovery workshops came first and produced the written rule set the build was tested against. We then built the database, the rule engine and the front end, migrated the investor data through the new dedup and validation step, and moved the team over once the new app matched the old tools' behavior on real records.
Before and after#
| Measure | Before | After |
|---|---|---|
| Business rules | Hidden in no-code tool settings | Cataloged and enforced in code |
| Duplicate investor records | Cleaned by hand after each import | Blocked at import |
| Time on manual data cleanup | Baseline | 60% less |
| Who can change investor data | Anyone with tool access | Authorized roles only |
What's next#
With clean, deduplicated investor history in one database, Praxis Rock can start using it to work smarter. Next up is retrieval over that history to help the team decide which investors to approach first and to draft a short briefing before each call.
