Services
I go in, fix it, leave
Two different jobs: fixing what already exists and building what does not yet. Bounded scope, written deliverables and a clean exit: when I am done, your people can sustain it without me.
Ways to work together
7 ways to start
Everything is quoted per scope: the price is set after the call, together with the work itself. No surprise rates halfway through.
Engagement 01
AI agents and agent teams
An agent that answers, quotes, books and escalates inside WhatsApp or your own system. And when one agent is not enough, a team of agents with separate roles and shared memory: one researches, one quotes, one charges.
What you get
- An agent trained on your real operation, not on a generic prompt
- An explicit escalation rule: if it does not know, it asks a human instead of improvising
- Memory that persists across conversations, plus a decision graph
- Connectors to what you already use: WhatsApp, payments, calendar, your own system
- Traceability: who answered what, and from which source
When it makes sense
- Your WhatsApp only gets answered out of hours, or not at all
- Your team copies and pastes the same answer twenty times a day
- You want to sell inside the conversation, not send the customer elsewhere
- You tried a bot and it answers things that are not true with total confidence
Engagement 02
Mobile app development
Apps with Flutter or Ionic on top of the backend you already have. What usually costs is not the screen: it is voice, calls, notifications, permissions and shipping.
What you get
- An installable, shippable app, with the build reproduced by a single command
- Integration with your existing API, without duplicating backend logic
- The hard parts solved: WebRTC for voice and calls, notifications, permissions, sessions
- A shipping and operating guide so it does not depend on me
When it makes sense
- You already have a web app or backend and need the mobile app
- The app exists but every release is manual and fragile
- You need calls or voice inside the app without locking into someone else’s SDK
- The team tried Flutter and does not know how to structure it to grow
Engagement 03
Websites and web platforms
Sites that load fast, index well and do not need a server to look after. This very site is the example: static, bilingual, no trackers, with the Open Graph cards generated at build time.
What you get
- A static or server-rendered site, whichever you actually need
- A design system of your own, not a bought template
- Technical SEO: canonical, hreflang, sitemap, Open Graph generated at build time
- Bilingual when your market demands it, with translated slugs
- Reproducible deploy in a single command
When it makes sense
- Your site does not show up when people search for your service
- It loads slowly, or falls over when a campaign runs
- Every change depends on someone remembering the steps
- You need two languages and the current site makes up odd URLs
Engagement 04
Architecture and technical-debt audit
A system that works but is frightening to touch. I review the code, the data model and the deployment, and leave you a risk map ordered by what it costs NOT to address it.
What you get
- A risk map ordered by the cost of ignoring it
- The coupling points already slowing delivery down
- A phased action plan, with an exit criterion per phase
- A walkthrough session of the report with your engineering team
When it makes sense
- You inherited a system nobody on the current team wrote
- The team is growing faster than the architecture
- You are raising capital and need to know what you are buying
- You ship slower every quarter and nobody knows exactly why
Engagement 05
Payment systems
Charges, subscriptions, webhooks and reconciliation. This is where a bug does not show up in a log: it shows up on the customer’s statement or on this month’s books.
What you get
- Idempotency through a unique database key, not an `if` in the code
- Webhook deduplication by provider event id
- Event-level reconciliation, with an append-only money journal
- A production checklist, including the PCI scope you have and the part you do not
When it makes sense
- Customers get charged twice, or you do, and nobody knows how
- Webhooks arrive late, twice, or never
- You need to reconcile what Stripe says against what your database says
- You are adding subscriptions and do not want to rewrite it later
Engagement 06
Infrastructure and CI/CD
Deployments that depend on someone remembering the steps. Containers, continuous integration, reproducible deploys, backups that actually restore, and the minimum alerting to sleep well.
What you get
- Reproducible deploy: one command, same result every time
- A pipeline that verifies before publishing, not after
- Backups with a tested, documented restore
- Minimum alerting and the runbook to operate it without me
When it makes sense
- The deploy is a manual ritual only one person knows
- There is no backup — or there is one and a restore has never been tested
- The server grew by hand and nobody knows what is installed on it
- You find out the site is down because a customer tells you
Engagement 07
Monthly technical advisory
For teams that already have someone writing the code and need someone deciding the architecture. I review the design before it becomes code, and the code before it becomes debt.
What you get
- Technical design review before the code is written
- Code review with an architecture lens, not a style lens
- Decisions written down and dated, including the alternative you rejected
- A block of hours each month for unblocking
When it makes sense
- You do not have a CTO and do not need one full time
- You have capable developers with no technical counterweight
- Decisions are made in chat and three months later nobody remembers why
- You need someone to unblock your team, not to replace it
How an engagement runs
From call to handover
- 01
A 30-minute call
You tell me what is breaking and what you already tried. If the problem is not architectural, I say so on that call and sell you nothing.
- 02
A written proposal
Scope, deliverables, dates and price. If you cannot predict what you will receive after reading it, it is not a proposal: it is an intention.
- 03
Execution with weekly checkpoints
Access to the repository and an environment where I can reproduce the problem. Every week, a written checkpoint: what is done, what is next, what is stuck.
- 04
Close and handover
Documented deliverables and a handover session. Success means your team can continue without me; if I am still required when it ends, I failed.
Next step
Shall we start with a call?
Thirty minutes to understand the problem and tell you whether I am the right person. If I am not, I will say so.