FAQ

Q1 | What is Dragon Lab?

Dragon Lab is a one-person technical consulting practice. I help teams turn complex engineering problems into clear, actionable decisions—without weeks of back-and-forth.

Q2 | Who is this for?

If you’re a startup, product team, or engineering lead dealing with real production constraints (time, reliability, cost), this is likely a fit—especially when you don’t have a staff/principal-level reviewer available internally.

Q3 | What kinds of problems do you help with?

Common situations I see:

• “We need an architecture sanity check before we scale this.”

• “The AI demo works, but production feels risky.”

• “The database is slowing down and optimization isn’t sticking.”

• “Incidents keep happening and we’re not sure what to fix first.”

Q4 | What services do you offer?

I focus on three areas:

• Architecture & Technical Review
  System boundaries, risk signals, trade-offs, and a practical plan.
  
  

• AI Features: Demo → Production
  Reliability, failure modes, evaluation, cost control, monitoring, and guardrails.
  
  

• Database Performance & Scalability
  Query bottlenecks, indexing, schema strategy, and scale-ready patterns.

Q5 | Are you an agency or a team?

No—Dragon Lab is just me. You get direct access, fast feedback loops, and fewer “communication layers.”

Q6 | Do you build or implement the work?

Usually, I don’t act as your delivery team. My core value is decision clarity and risk reduction.
If you want hands-on support, I can discuss it case-by-case—only when scope is clear and it truly helps.

Q7 | What will I receive after a consultation?

Depending on scope, you’ll get:

• A prioritized risk list (what matters most and why)

• Concrete recommendations with trade-offs

• A next-step plan (what to do this week vs. later)

• Optional: a short written summary you can share internally

Q8 | Do you need access to our source code?

Often, no. Many reviews can be done from:

• architecture diagrams (even a sketch)

• data flow / key workflows

• database schema shape and query patterns

• logs/metrics/error traces (redacted is fine)
  
  

If code access is needed, I’ll request the minimum necessary and define boundaries up front.

Q9 | How do you handle confidentiality?

I work with “minimum required context,” and I’m comfortable with anonymized or redacted materials. I don’t publish identifiable case details without explicit permission.

Q10 | How is this different from general consulting advice?

I don’t give abstract “best practices.” I focus on your system, your constraints, and what will actually move the needle. You’ll leave with decisions and a plan your team can execute.

Q11 | Can we start with a one-time session?

Yes. Many teams start with a single session to clarify priorities, then decide next steps based on what we find.

Q12 | What should we prepare before the call?

Three short items are enough:

1. Your biggest bottleneck (reliability, speed, cost, delivery)

2. The decision you’re stuck on

3. What “success” looks like after the call

If you have metrics or diagrams, great—but don’t over-prepare.

Q13 | Do you guarantee you’ll fix everything in one call?

No. But I will help you define the real problem, prioritize the risks, and choose a practical path forward—so you stop guessing.

Q14 | How do we get started?

Start on the Contact page to book a time and share a quick overview of your current challenge.

If you’re not ready to book yet, you can still use the Contact page to send a short message.