From conversation to finished product

A transparent process with no surprises. You know what you're getting, when and for how much — at every stage.

01

Initial conversation

I start with a casual conversation — no formalities, no slides. I want to understand your business, the problems you're trying to solve and what you expect from the system. There are no wrong questions at this stage.

  • Free consultation
  • Analysis of current processes
  • Setting priorities
02

User stories

Together we turn needs into concrete user stories — who wants to do what and why. I also think ahead about what you'll need down the road, so the architecture doesn't box you in.

  • User stories in business language
  • Feature prioritisation
  • Future-proof plan without technical debt
03

Estimate and plan

Based on the stories I prepare a detailed estimate and schedule. Split into stages — you pay for completed modules, not for time. No surprises along the way.

  • Estimate broken down by module
  • Schedule with milestones
  • Stage-by-stage payments
04

AI as a work tool

Optional

If you're OK with me using AI as a tool during development — delivery gets faster and costs go down. AI doesn't write code for me: I review, test and understand every line. Think of it as working with a very fast assistant.

  • Shorter delivery time
  • Lower development costs
  • The same quality and test coverage
  • Full transparency — I let you know when AI is used

I use AI as an assistant when writing code — scaffolding, docs, tests. Every line AI suggests gets read and understood by me before it goes into the project. The result: I deliver more in the same time, or the same scope for less. AI doesn't show up in the final product if you don't want it to.

05

Development

I build iteratively — after each stage you have working code you can test and give feedback on. No big reveal after six months of silence. Direct communication, no middlemen.

  • Iterative delivery — module by module
  • Access to a test environment
  • Regular status updates
06

Testing

My take is that 100% unit test coverage means nothing if the database integration or external API is broken. That's why I build my process around integration tests. I simulate real conditions in them: network delays, malformed protocol frames, service restarts. For me, 'code that works' is code that survived trial by fire in a test container — not just on my laptop.

  • Unit and integration tests
  • End-to-end tests
  • Failure scenarios and edge cases
07

Warranty

After delivery you get a warranty on everything I built. Bugs that come from my implementation get fixed for free. An optional support and ongoing development contract is also available.

  • Warranty on post-production bugs
  • Fast response to reports
  • Optional support contract

Ready to talk about your project?

Contact me