How we scope, build, and launch
Projects fail for predictable reasons: unclear scope, slow feedback loops, or a team that disappears after launch. This page describes how we run projects to avoid those, from the first call through the support phase after release.
Delivery chain
Discovery and design, signed off
Every stage ends with a written output you approve before the next one starts.
What a project runs on
A written scope before code
Discovery produces a scope document, a rough timeline, a list of integrations and dependencies, and a decision on stack. You get it in writing before any build work starts.
A build you can click
Two-week sprints end with a working build on a staging environment, not a status update. Weekly calls cover progress, blockers, and decisions that need your input.
One owner for decisions
Multiple stakeholders are fine, but every project needs one point of contact on your side. Projects stall when nobody can approve a design or answer a scope question.
A support phase, not a handoff
Most clients move into a monthly retainer after launch for bug fixes, dependency and OS updates, and small feature work. Retainers can be paused when you do not need active support.
The short version
Discovery ends in a written scope, design ends in a component library, build runs in two-week sprints, QA runs throughout, launch is planned with a rollback, and support is a monthly retainer you can pause.
Discovery: what we figure out before building
Discovery is where we learn what the product needs to do, who uses it, and what constraints exist. For a mid-sized project this phase runs two to four weeks. For smaller projects it is often a series of focused calls instead of a formal phase.
If you already have a technical team, discovery is where we agree who owns which layer. That conversation usually takes one call and saves weeks later.
Design: from wireframes to handoff
Design starts with user flows and wireframes, then moves to high-fidelity screens in Figma. We build a component library as we go, so developers have reusable pieces rather than one-off screens.
Handoff includes specs, states for every interactive element, and edge cases like empty states and error messages. If your team has an existing designer, we can work alongside them instead.
Flows and wireframes
Low-fidelity screens that settle navigation and screen order before visual design starts. Cheaper to change here than in code.
Component library
Buttons, inputs, tables, and states built once in Figma and mirrored in code, so the product stays consistent as it grows.
Build: how work is organized
We work in two-week sprints with a shared board, on Linear or Jira depending on your preference. Each sprint ends with a working build you can review, not a status update.
You get a staging environment from early in the project, so you can click through features as they are built. Weekly calls cover progress, blockers, and decisions that need your input. Agile delivery only works when the review loop is short, so we keep it short.
Sprint length
Two weeks
Shorter than a month so course correction stays cheap.
Review surface
Staging environment
Live from early on, so feedback happens on the real thing.
Board
Linear or Jira
Whatever your team already opens every morning.
QA and testing
Testing happens throughout, not only at the end. We run functional tests, cross-browser and cross-device checks, and, where relevant, accessibility and performance audits.
Launch: what happens on release day
Launch is planned in advance. We set a release window, prepare rollback procedures, and confirm who is on call if something breaks. For web projects, we deploy to production and monitor logs and error tracking for the first days after release.
For mobile apps, we handle store submission and the review process. Apple and Google reviews sometimes take longer than expected, so we build that into the timeline instead of promising a fixed date.
Before the release window opens
- A agreed release window and who from your side signs it off
- Rollback steps written down and tested, not improvised on the day
- Log and error tracking live before the first production request
- Store assets, descriptions, and screenshots prepared for mobile submissions
- A named person on call for the first days after release
Support after launch
After launch, most clients move into a support retainer. This covers bug fixes, dependency and OS updates, and small feature work. Larger feature additions are scoped as new projects.
What the retainer covers
Bug fixes, dependency and operating system updates, and small feature work that fits the current architecture.
What gets scoped again
Larger feature additions, new platforms, and integrations that change the product's shape. We quote those as new projects.
Monthly, and pausable
Retainers are monthly and can be paused if you do not need active support. We do not lock clients into long contracts.
Access to the same board
Support requests go into the board the project was built on, so history stays in one place instead of scattered across email.
IT consulting engagements
IT consulting engagements run differently. They are usually shorter and more advisory: an architecture review, a cloud cost assessment, or a vendor selection process. The output is a written recommendation, not a codebase.
Some consulting engagements turn into build projects. Others end with a report and no further work. Both are fine.
Staff augmentation and working inside your team
When we place engineers into your team, they join your standups, use your tools, and follow your process. You manage priorities; we handle hiring, payroll, and technical onboarding.
This model works best when you have a clear roadmap and need capacity, not when the roadmap itself is still being figured out.
What we ask from you
Clear decision-making and timely feedback matter more than anything else. Projects stall when nobody can approve a design or answer a scope question.
We also ask for one point of contact on your side. Multiple stakeholders are fine, but decisions need a clear owner.
If that sounds like your team, the fastest way to start is a scoping call. Bring what you already know about the product and we will tell you honestly whether the project needs a formal discovery phase or a few focused conversations.
Questions we get asked before a project starts
How long does discovery usually take? +
For a mid-sized project, two to four weeks. Smaller projects often run as a series of focused calls rather than a formal phase, and you still get the scope document and timeline in writing.
Can you work with our existing designer or developers? +
Yes. If your team has a designer, we can work alongside them on flows and components. If you have developers, discovery is where we agree who owns which layer so the interfaces line up.
What happens if the mobile store review takes longer than expected? +
We build the review window into the timeline rather than promising a fixed release date. The app is ready and submitted; the store decides when it goes live, and we tell you what we are seeing.
Do we have to keep a retainer running after launch? +
No. Retainers are monthly and can be paused when you do not need active support. If you come back later, we pick up from the same board and the same codebase history.
Can a consulting engagement stay advisory? +
Yes. An architecture review, a cloud cost assessment, or a vendor selection process can end with a written recommendation and no further work. Some engagements do turn into build projects, and that decision is yours.
Start with a scoping call
Bring what you already know about the product, the timeline you are working against, and the systems it needs to talk to. We will tell you what discovery would cover, who would be on the project, and what we would need from you to keep it on track.
Reach us Monday to Friday, 9:00 AM to 6:00 PM, at kanogml1201@gmail.com or +1 (815) 934-4003. Our studio sits at 19 Kote Marjanishvili St, Tbilisi 0102.