A new product to structure
Before writing code, you need to choose the building blocks, the module boundaries, the data model and how the app and the API talk to each other.
Expertise
Software architecture
that holds as
your product grows.
Software architecture design and review for mobile apps, web applications and APIs: modular structure, data model, API contracts, progressive migrations. Every structural decision is documented, with its alternatives and consequences.
decisionsDECISION 0008
Progressive migration
Replace the payment module step by step, behind the same interface, rather than rewriting the application.
REJECTED ALTERNATIVE
Full rewrite: new features would be frozen for the whole rebuild.
Consequences
Two implementations coexist during the migration; each wave can ship on its own.
● DECISION ACCEPTEDCONTEXT · ALTERNATIVES · CONSEQUENCES
Situations
When architecture becomes the issue.
Code that slows every change
Each feature weakens another, dependencies are tangled and the team no longer dares to touch some parts.
A structural migration
A change of framework, state management or database, to carry out without interrupting a product in production.
Decisions nobody can trace
Choices were made, but neither their reasons nor the rejected alternatives were written down. Every new team has to rediscover them.
Scope of work
What we design and document.
An architecture is judged by what it lets you change without breaking everything. We design it, document it and evolve it with the team that will maintain it.
Application architecture
Module boundaries, state management, navigation and dependencies for Flutter, Swift, Kotlin and Next.js applications.
APIs and backend
Business modules, documented API contracts, authentication and integrations, on NestJS and Node.js.
Data model
PostgreSQL schemas, versioned migrations, and the choice between relational and document databases based on usage.
Real time
Messaging, streaming and synchronisation: WebSocket, WebRTC, LiveKit or LL-HLS depending on target latency and cost.
Progressive migrations
Step-by-step replacement following the Strangler Fig pattern rather than a rewrite: the product stays live throughout.
Documented decisions
Diagrams versioned in Git, API contracts and decision records: every structural choice states the alternatives considered and its consequences.
Method
From the existing system to the target architecture.
- 01
Understand the constraints
Usage, volumes, team, deadlines and the existing system. An architecture answers constraints, not trends.
- 02
Propose and compare
Target architecture and possible options, with their costs, their risks and what they will make harder later.
- 03
Document the decisions
Diagrams, data model, API contracts and decision records, versioned with the code.
- 04
Support the implementation
Foundations, code review and step-by-step migration, alongside your team or by taking on the development.
Responsibilities
Who decides what.
A typical division of responsibilities, agreed for each engagement.
| Topic | Your team | Black Tide |
|---|---|---|
| Constraints | You share usage, volumes and deadlines | We turn them into architecture requirements |
| Structural choices | You approve the chosen option | We propose options and document their consequences |
| Documentation | You host it in your tools | We write it and keep it current during the engagement |
| Code review | Your process applies | We make sure architecture decisions are followed |
| Migration | You set the pace and priorities | We migrate step by step, without service interruption |
Selected work
Architectures proven in production.
Blisterr
A progressive Strangler Fig migration: the Flutter app moved to hooks and Riverpod in waves, while the backend is being migrated from MongoDB to PostgreSQL table by table, without service interruption.
Read the Blisterr caseFantasy Alley
Three connected blocks: a Flutter application, a NestJS API with around twenty business modules and a Python pipeline syncing around 125,000 books.
Read the Fantasy Alley caseEach case describes the work delivered, its scope and the current status of the product.
Budget and next steps
How an architecture engagement is scoped.
What discovery establishes
The architecture questions to settle, the existing system to examine and the expected deliverables: target architecture, data model, API contracts.
What makes up the budget
Design and documentation time, the size of the existing system to examine and, if requested, support during implementation.
A transferable architecture
Deliverables are written to be picked up by the team that builds, whether yours or ours.
Join at the stage you need
Architecture review only, design of a target architecture, or full support through implementation.
Useful questions
Before an architecture engagement.
Do we need microservices?
Not by default. A well-structured modular monolith suits most products and is simpler to operate. We split into services when a real constraint calls for it.
Can you work on an existing architecture?
Yes. We first examine the code and operations, then propose a step-by-step evolution path rather than a rewrite.
What deliverables do we receive?
Depending on scope: architecture diagrams, data model, API contracts and decision records, versioned with the code.
Do you work with our engineering team?
Yes. The architecture is designed with the team that will maintain it, as a project or embedded, so decisions are understood and applied.
Next step
Let’s talk about your architecture.
Your product, its existing technical base and what needs to evolve: the starting point for a useful review.