Fit and timing
For teams deciding whether the product needs an outside technical pass.
- What kind of app is a fit?
- The best fit is a working web app with real business value, a growing feature backlog, and increasing friction from generated code.
- When should we bring you in?
- Usually after the demo works, users care, and the next features feel risky because the code is hard to reason about.
- What problems usually trigger an assessment?
- Common triggers are repeated bugs, unclear ownership, duplicated logic, fragile deployments, weak test coverage, and fear of changing important flows.
- What is not a good fit?
- Very early throwaway prototypes, purely visual landing pages, and products with no current users or business process usually need product shaping before remediation.
Assessment and planning
What happens before any code changes are recommended.
- What do you need for a quote?
- A product summary, stack, repository status, deployment notes, and the next feature or operational risk that made the current app feel limiting.
- How long does an assessment take?
- A focused assessment is usually short and scoped. Stabilization work commonly lands in two to four week slices depending on risk and repo size.
- What do you review first?
- I start with the product goal, critical user paths, repo structure, data boundaries, deployment setup, and the areas your team already distrusts.
- What do we get from an assessment?
- You get a risk-ranked plan, rewrite-versus-remediate recommendations, key file references, and a scoped estimate for the highest-value next slice.
Remediation and modernization
How fragile generated code becomes easier to change safely.
- Is this a rewrite service?
- Not by default. I start by identifying what is already valuable, then replace brittle pieces only when that is cheaper or safer than stabilizing them.
- Will you keep the product running during cleanup?
- That is the point. The safest remediation plan preserves working behavior while moving risky pieces behind clearer boundaries.
- What areas do you usually fix?
- Typical work includes typed domain boundaries, shared utilities, auth and data checks, focused regression tests, CI gates, deployment cleanup, and agent instructions.
- Can you implement the fixes too?
- Yes. Some clients only need the assessment, while others continue into focused implementation sprints that remove the highest-risk issues first.
Agents and team workflow
Keeping AI coding tools useful without letting the repo drift.
- Do I need to stop using agents?
- No. The goal is to make agents safer by giving them clearer architecture, better repo instructions, typed contracts, and review gates.
- Can you work with an existing team?
- Yes. The work can be delivered as a focused implementation sprint, technical advisory, or a handoff package for your team to continue.
- What does agent-ready mean?
- It means the repo has clear instructions, stable patterns, type-safe boundaries, test commands, and review rules that help agents make smaller, safer changes.
- Will you document the decisions?
- Yes. The handoff usually includes repo instructions, decision notes, review checklists, and guidance on which future tasks need human engineering judgment.
Security and access
How sensitive code and production risks are handled.
- How do we share the codebase?
- Read-only repository access is enough for an assessment. Write access is only needed if we agree on an implementation sprint.
- Do you need production data?
- No. I prefer sanitized examples, schema information, logs, and deployment context. Real customer data should stay out of the review unless there is a specific approved need.
- Do you review security?
- Yes, at a practical product level: auth, authorization, secrets, validation, dependency risk, payment paths, and places where generated code may trust the wrong boundary.
- Can you sign an NDA?
- Yes. For private codebases or sensitive product context, an NDA can be handled before repository access is granted.
Engagements and outcomes
Scope, pricing, follow-on work, and what changes after the work.
- What stacks do you support?
- Most modern TypeScript web stacks are a fit, especially Next.js, React, Node, Postgres, Supabase, Stripe, Clerk, Vercel, and OpenAI-based products.
- What happens after the first sprint?
- You get a clearer codebase, a risk-ranked roadmap, and guidance on which future tasks are safe for agents versus senior engineering review.
- How is pricing handled?
- A fixed-price consultation is available for the first diagnostic. Implementation work is scoped after reviewing risk, repo size, and the outcomes you need.
- How long is a typical implementation sprint?
- Most useful sprints are two to four weeks. Larger modernization efforts are split into reviewable slices so the product keeps moving.
- Can you stay involved afterward?
- Yes. Follow-on work can be advisory, implementation-focused, or a lightweight review cadence for your team and agents.