Fintech Development: 7 Circles of Hell

Why Dante Would Have Made a Great IT Manager

When Dante described the circles of hell, he crafted the perfect metaphor for fintech development. Each circle is a separate kind of suffering, and passing one doesn’t mean the next will be easier. The difference is that Dante at least knew the route. Most teams enter banking development with startup-level optimism and a three-month plan.

I’ve been through all seven circles several times. Each time I came away with lessons you won’t find in any Agile manifesto. This isn’t a complaint or a scare story — it’s a map of the terrain so you don’t walk in blind.

Circle One: Hiring

“Abandon all hope, ye who enter here” — Dante, Inferno, Canto III

In a startup, you post a vacancy, a week later you have three interviews, in two weeks — someone on board. In a bank, hiring is a project unto itself with its own timeline and stakeholders.

Headcount approval. Requirements formalization through the HR system. Posting through corporate recruiting. Resume filtering. Interviews that need to be coordinated across five people’s calendars. Offer through legal review. Security check. Onboarding with access provisioning — that alone is two to three weeks.

In early 2024, I needed a Scala developer with Apache Flink experience. On the Russian market, specialists like that are literally a handful. The first suitable candidate appeared after two months. While the offer was being approved — he accepted another one. The second candidate showed up a month later. By the time he made his first commit, four and a half months had passed. The project was already on fire by then.

Bottom line: from identifying the need to the first working commit — three to four months. And the project was needed yesterday.

How to survive. Hire ahead of schedule — and learn to recognize red flags. If you know you’ll need more people next quarter — start now. Build a talent pipeline. Develop relationships with recruiting — they prioritize people who are easy to work with. And most importantly — be ready to grow expertise internally. The specialist you need might simply not exist on the market.

Circle Two: Bureaucracy

“Here no laments were heard, only sighs” — Dante, Inferno, Canto IV

A bank is a regulated organization. The central bank, auditors, security department. Every change in production is documented, approved, signed off. Not management’s whim — regulatory requirement.

A simple deployment turns into a quest: RFC, architecture committee approval, InfoSec risk assessment, business owner sign-off, entry in the change calendar. One missing link in the chain — deployment doesn’t happen.

I remember the first release of a new service. Code ready, tests green, APIs aligned, team on standby. Deployment scheduled for Thursday. Wednesday evening, InfoSec returned comments on the documentation — wording in one section didn’t comply with an internal standard. Postponed to next week. We rewrote the section. Monday — new comments, this time from the architecture committee. Total: from ready code to production — three weeks of paperwork.

Documentation is a separate kind of pain. Technical design, working design, admin guide, user guide, system passport. Documentation consumes twenty to thirty percent of the team’s time. Developers who came from startups spend their first month thinking it’s a joke.

How to survive. Don’t fight the system — use it. Automate documentation generation. Create templates that cover eighty percent of requirements. Build personal relationships with approvers — when someone knows you, the process speeds up dramatically.

Circle Three: Shifting Requirements

“The eternal wind drives them, giving no rest” — Dante, Inferno, Canto V

The business stakeholder comes with an idea. You lock in the scope, estimate timelines, plan resources. Two weeks later: “We’ve been thinking, and we also need this.” A month later — again. After two months — scope has doubled, deadline hasn’t moved.

Not malice — the nature of banking business. The regulator issues a directive — plans go out the window. A competitor launches a feature — the business wants the same thing, yesterday. The market shifts — priorities follow.

On one project, we changed the target data model three times in six months. Not because we designed it poorly — because the business process we were building the system for was itself changing faster than we could keep up. Each time — architecture review, data migration, test rewrites. The team joked that our real product wasn’t the system, but the process of rebuilding it.

How to survive. Put scope in writing, with a signature. A change request isn’t bureaucracy — it’s a transparency tool. Every change = revised timelines and resources. The business has every right to change requirements, but must understand the cost. And design your system to survive these changes — modularity isn’t for aesthetics, it’s for survival.

Circle Four: Resource Scarcity

“They push great weights, shouting at one another” — Dante, Inferno, Canto VII

You’ve designed a system that needs four servers with specific specs. You file a request. A month later — two servers with different specs. Two months later — one more, but in a different data center.

True story: we waited three months for load testing servers. When we got them — the configuration didn’t match the request. Half the RAM. Filed a new request for upgrades. Another month. In the end, we ran load testing on hardware that didn’t match the production configuration. And the Tarantool bug we found later could well have surfaced earlier — if the infrastructure had been right.

People are an even scarcer resource. You need a developer with a specific stack, and there are only a handful on the market. The DevOps engineer who knows corporate Kubernetes is loaded across three projects simultaneously.

How to survive. Design for constraints, not in a vacuum. A working system on two servers is better than a perfect architecture that will never get the hardware it needs. Grow T-shaped people within the team — when everyone can pick up an adjacent task, you’re not paralyzed by one person’s vacation.

Circle Five: Conflicts

“Sullen were we in the sweet air” — Dante, Inferno, Canto VII

Dozens of people from different departments work on a single product at a large bank. Everyone has their own KPIs, priorities, and idea of “the right way.” Conflicts are inevitable.

Business wants faster, development wants higher quality. The architecture committee wants standards, the team wants freedom. QA wants full regression, business wants to deploy tomorrow. InfoSec wants to lock everything down, development wants access to everything.

The most memorable conflict: an adjacent team changed the API format without warning. On a Friday evening. Our service started dumping events into the Dead Letter Queue — by the thousands. The on-call engineer raised the alarm, we rolled back their change, and Monday began with a postmortem. Turns out they had their own deadline, and “we thought you’d already switched to the new format.” Nobody checked. Nobody posted in the chat. Lesson: a contract between teams isn’t a document in the knowledge base — it’s a living process.

How to survive. Conflict isn’t a problem — it’s an indicator of imbalance. Look for win-win. Build personal relationships with leads of adjacent teams. Escalate only when everything else is exhausted. And set up a shared channel for breaking changes — seriously, it saves lives.

Circle Six: CI/CD in Enterprise

“In open graves, lying in flames” — Dante, Inferno, Canto IX

In a startup — GitHub Actions in a day, deploy at the click of a button. In a bank, CI/CD is a corporate platform with policies, restrictions, and queues.

A corporate CI/CD pipeline with custom plugins. Docker images only from the internal registry. Dependencies only from corporate Nexus — and if the version of a library you need isn’t there, you don’t just add it, you file a request to whitelist it. Production access — through a separate pipeline with manual approval.

The first deployment of our new service took a week. Not because the code was bad — because you need to configure the pipeline, get access, register the service in the service mesh, set up monitoring and logging per corporate standards. The second service — three days: we already knew the route. The third — one day. The learning curve is steep, but it exists.

How to survive. Start CI/CD setup on day one of the project. Create internal documentation for the pipeline — for subsequent services, the process will be three times faster. Automate linters, tests, security scanning. And most importantly — befriend the team that owns the platform. They know the shortcuts.

Circle Seven: Support

“We came to the river of boiling blood” — Dante, Inferno, Canto XII

You’ve passed six circles, product is in production, the stakeholder is happy. Time to relax? No. Now begins the longest circle.

Incidents at 3 AM. Degradation from data growth. Bugs that only appear in specific scenarios. Minor enhancements that turn a clean architecture into a patchwork quilt.

3 AM, PagerDuty alert. Scoring service latency has spiked fivefold. The on-call engineer gets up, checks dashboards — everything is red, cause unclear. Turns out: one of the legacy systems started sending events in a different format after its own overnight release. Which, of course, nobody told us about. Deserialization didn’t crash — it worked slowly, parsing non-standard fields. Silent degradation — the most dangerous kind.

And the most painful thing — people leaving. The team that built the product moves on to new projects. Newcomers don’t have the context, documentation is outdated, every incident is a detective investigation.

How to survive. Build support into the architecture from day one. Observability isn’t optional — it’s a requirement. A runbook for every alert. A knowledge base that gets updated. Rotation of on-call shifts so there’s no single “keeper of knowledge” without whom everything grinds to a halt.

Survival Map

Circle	Pain	Survival Tactic	Typical Cost
1. Hiring	Finding the right person in reasonable time	Hire ahead, grow from within	3-4 months per position
2. Bureaucracy	Approvals kill velocity	Templates, doc automation, personal connections	20-30% of team time
3. Requirements	Scope creeps, deadline doesn’t	Change requests, written contracts, modularity	Redesign once a quarter
4. Resources	No servers, no people	Design for constraints, T-shaped people	Months of waiting
5. Conflicts	KPIs across teams don’t align	Win-win, personal relationships, shared channels	A week per incident resolution
6. CI/CD	Corporate platform isn’t GitHub	Documentation, automation, befriend the platform team	A week for first deploy
7. Support	Night incidents, attrition	Observability, runbooks, on-call rotation	Infinity

The Eighth Circle Dante Didn’t Write About

Dante stopped at nine circles. He didn’t know about production deployments on Friday evening. About change freezes before the holidays, when the business stakeholder “really needs just one last tiny feature.” About migrating to a new Kubernetes version inside a banking perimeter when you don’t have admin privileges, and those who do have no context about your service.

Fintech isn’t for everyone. But if you’ve passed seven circles and didn’t burn out — every other project feels like a vacation. And a map drawn from other people’s scars saves you at least a couple of your own.

Just don’t deploy on Friday. Seriously. Even if they really ask.

---

Original article: Fintech Development: 7 Circles of Hell on Habr

— Vladimir Lovtsov