The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Many backend integration projects don’t fail because the API is hard.
They fail because the business flow is unclear.
A customer books an appointment.
Then submits a digital form.
Then the bank processes the transaction.
Then a PDF is generated.
Then WhatsApp or email notifications are sent.
Sounds simple.
But then the real questions appear:
What if the booking is cancelled?
What if the form was already submitted?
Who decides whether the transaction is completed?
When should the PDF be generated?
Which status should trigger the customer notification?
If these questions are not clarified before development, the backend quickly becomes a pile of patches.
I created a short architecture discovery case around a paperless banking workflow integration.
The main idea:
The Booking Lifecycle and the Bank Transaction Lifecycle should be separated.
One answers:
“Does the customer have a valid appointment?”
The other answers:
“Where is this banking transaction in the internal process?”
This is the kind of backend/API integration work I enjoy most:
turning messy business workflows into clear, buildable system design.
Full case study:
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Challenges
View all
Related posts
AI Agent Developer work is most useful when context survives the handoff. On Tenderseal, I structured the flow around reading source material, asking focused questions, and drafting from that context. The product has supported 15+ European companies, while the workflow stays traceable back to the material. I build real integrations with approval points and read-back rather than hiding the hard step behind a chat box. Message me if a document workflow is losing context between people and systems.
AI Agent Orchestrator decisions determine whether a useful assistant stays useful after day one. For MeetClaw, I design which channels it inhabits, which model provider it uses, and where its state lives before the installation begins. I have organised 3 self-funded buildathons around OpenClaw, Claude Code and Hermes, so I have seen the failures that a topology has to prevent. I work with approvals, read-back and live integrations so the operator can inspect the system. Message me with the workflow that needs coordination.
I’ve been building SabiFlow for a while, and honestly, the most interesting part of the project isn’t the code.
It's the problem.
Because it's personal.
I've experienced that thing where money comes in and somehow, without you really noticing, it starts disappearing.
Not because you don’t earn enough.
Not necessarily because you're irresponsible either.
Sometimes money simply has no job when it arrives.
And as an engineer, that got me thinking:
What if the problem isn't budgeting? What if the problem is that we’re asking people to make too many good decisions at the exact moment they have the most temptation to make bad ones?
That question became the foundation for SabiFlow.
Instead of telling someone, "You should save 20% of your income," I started thinking about what would happen if the system simply helped assign every inflow a purpose the moment it arrived.
That led me down a rabbit hole.
Funnels.
Automated distribution.
Wallet infrastructure.
Virtual accounts.
User behaviour.
Transaction flows.
KYC.
Compliance.
Even the psychology behind notifications.
And this is probably my favourite part of being both an engineer and a founder.
I don’t just ask:
"How do I build this feature?"
I ask:
"Why does this problem exist, and what kind of system could make dealing with it easier?"
Then the engineer in me comes along and asks:
"Okay… but how do we actually make this work reliably?" 😂
That tension between the founder thinking about the problem and the CTO thinking about the system is probably what I enjoy most about building SabiFlow.
I’m still figuring a lot of it out.
But I'm curious:
What’s a problem you’ve experienced personally that eventually made you want to build something around it?
The framing around “why does this problem exist?” is exactly the kind of product thinking that keeps a financial tool from becoming another dashboard. SabiFlow sounds strongest where the behavioral insight meets the practical system design—especially around notifications and reliable follow-through.