Building financial software is not just about shipping features, integrating APIs, or getting an application approved by an app store. It also requires clear agreements about ownership, compensation, accountability, and what happens when the people building the system no longer agree.
I learned this through my involvement in Amalfi, a blockchain-based financial platform now publicly available as Amalfi Global Bank.
Google Play: https://play.google.com/store/apps/details?id=com.amalfi.banking
Apple App Store: https://apps.apple.com/br/app/amalfi-global-bank/id6755686818
My work involved significant technical components of the platform. Over time, however, the professional relationship behind that work became the subject of an unresolved dispute involving outstanding financial matters, intellectual property rights, and the terms under which I could formally disengage from the project.
This is where things became difficult.
In our communications, I was repeatedly described not merely as a developer, but as a partner who would help lead technology and future development. There are written messages documenting those conversations, as well as discussions acknowledging outstanding matters that still needed to be resolved.
Yet the relationship never reached a definitive written settlement addressing all the issues now in dispute.
My position is that the technical work, the financial obligations, and the rights associated with the software need to be addressed formally. The other party disputes aspects of my account. No final agreement has resolved the disagreement, and I am pursuing the appropriate formal channels rather than presenting contested claims as established legal findings.
I am not publishing this to encourage harassment, interfere with customers, or ask anyone to take sides without examining the facts. I am publishing it because there is a broader engineering lesson here.
If a company depends on critical software, the relationship with the people who build it cannot be managed through informal promises indefinitely.
A project can have a public application, a product roadmap, external integrations, and a compelling financial narrative while the agreements governing its underlying engineering work remain incomplete.
That is a governance problem, not merely a personal disagreement.
For engineers working on fintech, blockchain infrastructure, or any security-sensitive system, I would take several lessons from this experience:
- Define compensation, equity, and partnership status in writing. They are different arrangements and should never be left ambiguous.
- Establish software ownership, licensing, and assignment terms before a dispute arises.
- Record deliverables, acceptance criteria, dependencies, and external blockers in a way that both parties can audit.
- Define what happens when a contributor leaves, including access revocation, handover, ongoing support, and the rights to existing work.
- Treat intellectual property and engineering continuity as first-class governance concerns, not paperwork to postpone until the product succeeds.
I still believe the engineering work should be evaluated on its actual merits. I also believe that financial and intellectual property disputes should be resolved through evidence, proper agreements, and the appropriate legal processes.
But technical professionals should not have to rely solely on trust and informal assurances when building infrastructure that a business intends to operate commercially.
Ship the software. Document the work. Define the rights. Put the agreement in writing before success makes the ambiguity expensive.
That lesson cost me more than I expected to learn, and I hope other engineers can learn it without having to go through the same experience.
Top comments (0)