Start with the
hard part.
Five ways to work with us. Most engagements begin with the architecture, because that is the decision that costs the most to reverse — and the one where an outside opinion is worth the most.
Technical assessment
Send us the problem. We’ll tell you what we see.
Send an architecture, a product, or a technical problem you are stuck on. We will read it properly and come back with the major technical risks we can see and a sensible path forward. Then a 15–20 minute conversation if it is useful to you.
There is no fee for this, and no deck or discovery call to book another call. If we are not the right people for the problem we will say so, which is a faster answer than a proposal.
- You send
- Architecture, repo, or a written problem
- You get
- Technical risks, and a path forward
- Then
- A 15–20 minute conversation, if it helps
- Reply
- Usually within a few hours
- Fee
- None
Or email business.maatx@gmail.com directly.
Five ways in.
Ordered by commitment. Most clients start at the top, and plenty stop there with an architecture they can take anywhere.
Discovery & Architecture
You have an idea, or a technical problem you cannot yet size.
From $4,500
1–3 weeks
We take the problem apart before anyone estimates it. You leave with an architecture you could hand to any competent team, and an honest list of what is likely to go wrong.
- Product and scope breakdown
- System architecture and data model
- Technical roadmap, sequenced by risk
- Risk analysis with the failure modes named
- Build-or-buy calls on each component
MVP Engineering
The architecture is settled and you need it running.
From $35,000
6–12 weeks, typically
Validated architecture through to a product in production — not a prototype that has to be rewritten before its first real user.
- Working product, deployed
- API and data layer built to the agreed contracts
- Instrumentation from day one, not retrofitted
- Deployment pipeline and rollback path
- Handover documentation your own team can work from
Product Modernization
Something works but is slow, fragile, or expensive to change.
From $8,000
2–8 weeks
An audit that finds the actual constraint rather than the obvious one, then the work to remove it. Usually the fix is in a data model or a boundary, not in the code everyone suspects.
- Architecture and performance audit
- Bottlenecks measured, not guessed
- Prioritised remediation plan
- The high-value fixes implemented
- Scaling path with the next ceiling identified
AI Engineering
You need an AI system that holds up in production.
Typically $25,000–120,000
Scoped per system
Retrieval that stays grounded, agents that are replayable, and evaluation that runs before anything ships. The model is one component with a contract, not the product.
- RAG and knowledge systems with grounded answers
- Agents with typed tools, permissions and approval gates
- Document intelligence and extraction pipelines
- Evaluation harness and observability
- Integration into the systems you already run
Blockchain Engineering
You are building on-chain and need more than a contract.
Typically $25,000–120,000
Scoped per system
The contract is one layer of eight. Most of what decides whether an on-chain system survives production lives in the indexing, the risk model and the reconciliation.
- Smart contracts, audited and upgrade-aware
- Reorg-safe indexing and event delivery
- Risk models and policy engines
- A ledger that reconciles, with breaks raised
- The application on top of all of it
These are starting points for the scope described, not estimates for your project — turning one into the other is what the first conversation is for. Ongoing engineering runs at $75 per hour blended.
What we build.
The first three overlap on most real projects. The fourth stands slightly apart — visual work rather than systems work — and it is here because clients keep needing both.
AI Engineering
We build production AI systems, not chatbots.
- AI agents
- RAG and knowledge systems
- AI customer operations
- Document intelligence
- Workflow automation
- Evaluation and observability
Blockchain & Fintech Engineering
We build blockchain systems beyond the smart contract.
- Contracts, backend and frontend
- Payments and settlement
- Tokenization and RWA
- DeFi and prediction markets
- Wallets and key management
- Indexing and multichain infrastructure
Product & Backend Engineering
We take difficult products from architecture to production.
- MVPs
- Backend systems and APIs
- Distributed systems
- Cloud and infrastructure
- Modernization and scaling
- Performance and reliability
3D, CGI & Visualization
Show a product before it exists.
- Photorealistic product renders
- Product animation and CGI ads
- Brand films and social CGI
- Product and hard-surface modeling
- Texturing and materials
- Production-ready real-time assets
How we build.
Five stages. Each produces something concrete — a decision, a design, working software — rather than a status update.
- 01
Understand
We work out what the system actually has to do, and what happens when it does not.
- Problem definition
- Constraints & risk
- Success criteria
- 02
Architect
Decisions that are expensive to reverse get made deliberately and written down.
- System design
- Data model
- Failure modes
- 03
Build
Vertical slices that work end to end, verified as they land rather than at the end.
- Incremental delivery
- Tests that matter
- Working software
- 04
Launch
Staged rollout with the instrumentation to tell whether it is going well.
- Progressive release
- Observability
- Rollback path
- 05
Scale
Performance, cost and reliability work driven by what production actually shows.
- Load & cost
- Hardening
- Iteration
What our work proves, and what it doesn’t.
The systems in our work section are MaatX product demonstrations — engineered interfaces and architectures, not client deployments. We say so on every one of them, and we are not going to dress them up as case studies.
What they do prove is the part that is hard to fake: that we can take a difficult domain, decide how the system should be structured, and build something that runs. That is the thing you would be hiring.
Every one of them is open to read. Pick the one closest to your problem and judge the engineering.
What are you trying to build?
Tell us the problem rather than the spec. If there is a sensible path we will outline it, and if there is not we will tell you that too.