Workflow
Map the work, decisions, users, and constraints.
Ship the AI feature your roadmap keeps waiting for.
Prototype
Validate the interaction with a working thin slice.
Risks
Surface model, product, cost, latency, and failure risks.
Build scope
Define what to build, what not to, and the handoff boundary.
Blacksmith / CI debugging
Ansaline / Founder-built productFive days to a decision you can build from.
A focused sprint from ambiguity to a working proof and a responsible production boundary. You leave with clarity, not another deck.
See how the sprint worksSelected engineering work, inspected up close.
Product and engineering decisions that shipped in real systems. These are work-history proofs, not borrowed logos or invented client outcomes.
Engineering work at SuperblocksShipped
Versioning inside a visual app builder
- Challenge
- Give teams Git-like confidence without pulling them out of the editor.
- Work
- Built the persistent Versions sidebar, commit preview, deployment history, deploy and reset flows, and end-to-end coverage.
- Result
- Merged product work that made changes, releases, and recovery navigable inside the builder.
Engineering work at BlacksmithShipped
Making CI failure data explorable
- Challenge
- Turn dense logs, traces, and cache records into debugging surfaces that stay useful under real volume.
- Work
- Built job-detail traces, virtualized log navigation, log comparison, keyboard search, and server-side cache pagination.
- Result
- Merged, tested workflows that help engineers move from a failed job to the evidence behind it.
Founder-built productShipped
A vertical answering product, from core to launch
- Challenge
- Combine a voice demonstration, durable customer workflows, and an acquisition surface in one coherent system.
- Work
- Built the product core, customer and admin workflows, lead operations, and a website-to-receptionist setup path.
- Result
- A live product with production workflows, deployment evidence, and a validated customer journey.
Start small enough to learn. Finish specific enough to build.
The sprint isolates one valuable interaction and tests the parts most likely to make or break it: user behavior, model behavior, latency, cost, failure handling, and the integration boundary.
Repo-free first engagementResolve the product behavior.
Map the user, the moment, the source data, the success criteria, and what the feature must do when the model is uncertain.
Build and pressure-test the thin slice.
Implement the interaction, compare viable model approaches, and test representative success and failure cases.
Make the build decision.
Review the proof, tradeoffs, risks, and a fixed production scope your team—or Levships Studio—can carry forward.
You leave with
- A working thin slice of the feature
- The product decisions behind the interaction
- Model, cost, latency, safety, and failure-mode findings
- An evaluation approach with representative test cases
- A production build scope with explicit boundaries
If the proof holds, the production path is already visible.
A follow-on build is scoped separately around a clean feature or service boundary. It can include production UX, evaluations, failure handling, observability, security review, deployment, and a documented handoff.
Move from proof to dependable software.
A bounded implementation with the same senior owner from product decision through release.
Keep senior product-engineering judgment close.
Ongoing design, technical direction, and high-leverage delivery for teams that do not need another full-time layer.
One senior owner from the first question to the final handoff.
I’m Lev Arakelyan, a full-stack engineer and product designer with more than fifteen years of experience building software. I use AI where it creates leverage, but I keep product judgment, architecture, implementation quality, and accountability human.
That means fewer translation layers: no account manager rewriting your brief, no junior handoff, and no gap between the person shaping the interaction and the person shipping it.
See the agency partner modelQuestions worth resolving before the call.
Do you need access to our repository?
Not for the feasibility sprint. We use public, synthetic, or supplied sample data to prove the product behavior and define a clean integration boundary. Repository access comes later only if a production build needs it.
What is working after five business days?
A focused thin slice of the feature, not a staged video or a strategy deck. You also leave with the decisions, risks, evaluation approach, and build scope needed to move forward responsibly.
Can you build the production version too?
Yes. Production work is a separately scoped follow-on with explicit boundaries, testing, observability, security review, deployment, and handoff. The sprint is useful even if another team builds it.
Is this autonomous AI development?
No. AI accelerates implementation. Lev personally owns product judgment, interaction design, architecture, code quality, evaluation, and the handoff.
Bring the feature that keeps slipping.
We’ll decide whether a five-day feasibility sprint is the right next move. If it is not, I’ll say so.