Four stages, start to handover.
- Cadence
- Working builds at agreed review points
- Commercials
- Milestone-based, priced in advance
- Access
- Direct founder ownership, throughout
- Handover
- Repositories, accounts, runbooks
01
The stages
Discover, design, build, improve.
A Kramiva project runs in four stages, each closed by a decision rather than by a date. Every stage names what you provide, what Kramiva delivers, and what has to be agreed before the next one starts — so at any point in the project you can say exactly where it is.
01
Discover
Understand the business before the software.
A working session on goals, users, constraints, existing systems, and what success has to look like commercially. Where the requirements are still open, discovery runs as a short paid stage of its own.
- You provide
- Your goals, existing systems, and whoever knows how the work is done today.
- You receive
- A written problem statement, a scope with fixed milestones, and an honest fit assessment — including a no, if that is the answer.
- Stage ends when
- You approve the scope and the milestone plan, or we part on good terms.
02
Design
Decide how it looks and behaves, in real screens.
Interface design against your real content. You review working screens rather than moodboards, and the design system is built as production components.
- You provide
- Brand assets where they exist, real content, and feedback on each round.
- You receive
- A design system and production-ready interface design that you own.
- Stage ends when
- You sign off the screens that engineering will build.
03
Build
Engineer it properly, in visible increments.
Typed, tested engineering in reviewable increments, verified against the performance and accessibility targets written into the scope before launch rather than after it.
- You provide
- Review time at the agreed cadence, content, and access to any systems being integrated.
- You receive
- Working builds shared at agreed review points — typically weekly where the engagement supports that cadence — and a pre-launch report covering performance and accessibility.
- Stage ends when
- Each milestone is accepted against its written criteria.
04
Launch and improve
Ship it, hand it over, and keep it moving.
Deployment, monitoring, and analytics, then transfer of repositories, accounts, and documentation with a working session for whoever will run it.
- You provide
- Domain and account access, and a person who will own the system afterwards.
- You receive
- Handover of source code, accounts, and runbooks on the terms set out in the project documents, plus a defined post-launch support window.
- Stage ends when
- You can run the system without us. Whether we continue is then your choice.
02
Engagement shapes
Three shapes a project takes.
These are shapes, not quotes. Scope and price are fixed in writing after a scoping call — as a fixed scope against milestones for a defined build, or a monthly arrangement for work that continues.
- Website or storefront
- A business website, redesign, landing page, or online store, shipped to a date. 5 – 10 weeks
- Focused product build
- A focused SaaS MVP, client portal, internal tool, or an AI capability inside an existing product. 3 – 6 months
- Ongoing support
- Something already live that should be maintained and improved rather than left to age. Monthly, with notice
03
Straight answers
What clients ask before starting.
- How does a Kramiva project begin?
- It begins with a short inquiry and a scoping call. You send a brief through the contact form, a founder replies within one business day with an honest read on fit, and if it looks right we run a discovery session and write a scope before any work starts.
- How are changes and feedback handled?
- Refinement inside an agreed milestone is part of the job and is not charged separately. A genuine change of direction is re-scoped in writing and priced before the work starts, so nothing arrives as a surprise invoice.
- How is project progress communicated?
- Through a deployed build you can open, updated at agreed review points — typically weekly where the engagement supports that cadence — plus a live review in an agreed window inside your working day. Progress is something you click through rather than something you read about in a status document.
- What happens if something goes wrong or runs late?
- You hear it in the first review it becomes visible in, not at the milestone it would have derailed. We say what has slipped, what caused it, what it costs in time, and the options — cut something, move the date, or change the approach. You choose. A risk we can see coming is raised while it is still a risk.
- What happens after launch?
- You receive the repositories, the accounts, the documentation, and a defined support window for defects. From there a monthly maintenance arrangement is available, covering updates, small features, and performance work. Continuing is optional — the handover is complete either way.
- How are projects priced?
- Projects are scoped according to requirements, timeline, and complexity, then fixed in writing against named milestones before work begins. The inquiry form asks for an approximate budget range so we can recommend a realistic scope. There is no rate card: the same brief can be a four-week project or a four-month one.
- Who owns the source code after delivery?
- You do. The code Kramiva writes for you transfers on final payment, with the documentation needed to run and extend it without us, and there is no proprietary Kramiva framework to keep paying for. Open-source dependencies and third-party services stay under their own licences, as they do in any build. Ownership, source-code transfer, and the treatment of any pre-existing or third-party components are defined in the signed project documents.
04
Contracts and data
What is agreed before we start.
- Confidentiality
- A mutual NDA is available before scoping, and we will sign yours rather than insisting on ours.
- Data processing
- Where a project processes personal data, the processing terms and the hosting region are agreed in writing before the build starts, and a data-processing agreement can be included where the engagement requires one. Material infrastructure and service-provider dependencies are disclosed where they are relevant to the engagement.
- Repositories and accounts
- Projects are built in client-owned or transferable repositories and accounts, agreed before engineering begins, so there is nothing to untangle at the end.
- Ownership
- Ownership, source-code transfer, and the treatment of pre-existing or third-party components are defined in the signed project documents.
Tell us what you are building.
A short brief gets you a real reply from a founder within one business day — an honest read on fit, scope, and budget.