The app
App not working
as it should?
The demo looked good. Real use tells a different story. You need to understand what breaks and how to fix it.
SOFTWARE & TECHNOLOGY ADVISOR
Stuck app. Fragile setup. Tough technical call.
Let’s get to work.
The app
The demo looked good. Real use tells a different story. You need to understand what breaks and how to fix it.
The setup
Services, access and deployments have become hard to follow. You need a clearer view of what connects and what could go wrong.
The decision
There are plenty of tools and ways to build it. You need to weigh the tradeoffs and choose what fits your product.

20 years building software.
I’m Hugo. I lead architecture for several AI apps and guide engineering teams through complex technical decisions.
I stay hands-on with the software: reviewing code, solving problems, and helping teams test and release with confidence.
I translate business goals into scoped technical plans, explain the tradeoffs in plain language, and follow the work through deployment.
Software, systems and decisions
Product engineering
Trace one core task, handle failure paths, and check deployment and recovery.
Read the studyCodebase clarity
Follow the behavior, protect what works, and simplify one code boundary at a time.
Read the studyAI costs
Measure cost per completed task, including retries, against quality and response time.
Read the studyTechnical decisions
Compare pronunciation, delivery and streaming using the phrases your product actually needs.
Read the studyInfrastructure
Map sensitive data, review access, and connect safeguards to risks, owners and evidence.
Read the studyA clearer next move
Software / Infrastructure / Technical directionBring the problem.
We’ll find the next move.
Start with a 15-minute fit call.
See whether we’re a fit.
Yes. We trace where it breaks, review the code and work through the fix.
No. Finding the problem is part of the work.
We discuss the project and whether we’re a fit. A paid session can follow.
We agree the scope and fee, then work through the code, infrastructure or decision.
Yes. We agree the focus and how often to work together.
Bring the problem.
We’ll work through the next step.
Product engineering
The demo is a beginning. The next step is a product that people can use, and a team can change with confidence.

The challenge
What happens outside the happy path? Which parts are real, which are temporary, and what breaks when a second person uses the app? Adding more features can make those questions harder to answer. The useful starting point is the smallest complete journey the product needs to support.
The approach
Begin with the product people actually need to use. Follow the code, data and external services behind that journey before deciding what to keep, repair or replace.
Follow a user action from the interface to stored data and back. Identify assumptions, temporary behavior and missing failure states.
Separate launch essentials from later features. Prioritize the failures that would prevent someone from completing the core task.
Define the checks, deployment steps and recovery path needed to release that scope deliberately.
What to verify
A useful result is more than a cleaner demo. It is a clear release scope, a tested core journey and an explicit account of the remaining risks.
Codebase clarity
When every fix creates another surprise, the first job is to make the system understandable again.

The challenge
Repeated prompts can leave similar logic in several places, conflicting assumptions and features that depend on accidental behavior. A rewrite may look attractive, but it also risks discarding working decisions that nobody has documented. First, find the part of the system that is making change difficult.
The approach
Use a real failure or difficult change as the entry point. Build enough understanding to improve that path without turning the entire codebase into a new project.
Trace the relevant inputs, state changes and outputs. Separate observed behavior from what the code appears intended to do.
Add focused checks around the behavior that must survive. Make uncertainty visible before moving responsibilities between modules.
Remove a specific duplication or dependency, then verify the same behavior still works. Leave a clearer place for the next change.
What to verify
The useful evidence is a change that can be explained, reviewed and verified without relying on another round of guesswork.
AI economics
Find the cost of a useful outcome before deciding which model, prompt or workflow to change.

The challenge
An app can spend money on long context, repeated requests, retries or work that never produces a useful result. Choosing a cheaper model without understanding the workflow can move the cost somewhere else. The question is what the app spends to complete a task well.
The approach
Use representative tasks and a consistent definition of an acceptable answer. Evaluate cost changes alongside the quality and response time the product needs.
Connect requests and retries to a user task. Capture the cost, latency and outcome of that complete path.
Look for duplicated calls, unused context and repeated processing. Distinguish waste from work that protects answer quality.
Test a focused change to the model, context or workflow against the same task set. Include failures and retries in the comparison.
What to verify
A useful result makes the tradeoff visible: what changes in cost, which quality conditions still hold and what happens to latency.
Technical decisions
A beautiful voice sample is only one part of a text-to-speech decision.

The challenge
The voice may need to handle names, numbers, unfamiliar words or different speaking styles. The product may also need streaming output, predictable response time or specific usage terms. A useful comparison starts with the experience being built, rather than a favorite demo.
The approach
Agree on what good sounds like and what the system must support. Give candidate models the same representative material and record the tradeoffs.
Identify the audience, languages, tone and difficult phrases. Define the product constraints before reviewing samples.
Compare pronunciation, consistency and delivery with representative scripts. Listen beyond a single showcase sentence.
Review response time, streaming behavior, cost and usage terms alongside the listening results. Keep the reasons for the choice visible.
What to verify
The useful result is a documented decision: where the selected option fits, which compromises it introduces and what would justify revisiting it.
Infrastructure
Make the flow of sensitive information, the system boundaries and the operating responsibilities explicit.

The challenge
A healthcare system raises questions about where sensitive information travels, who can reach it, which vendors are involved and how the system is operated. Those questions need a shared view of the environment and its responsibilities before technical changes are prioritized.
The approach
Frame the technical review around actual data flows and the safeguards in scope. Coordinate the engineering work with the people responsible for privacy, security and compliance decisions.
Identify where sensitive information enters, moves and is stored, including logs, backups and external services.
Ask who can reach each part of the system, how that access is managed and who owns the relevant operating decisions.
Connect the proposed controls to the identified risks. Define what evidence would demonstrate that the controls work in the environment.
What to verify
Keep the technical scope, control owners and unresolved risks together. Each safeguard needs evidence that it works in the environment, so the engineering review can inform the people responsible for privacy, security and compliance.