How I work
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.
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
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
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
AI as a work tool
OptionalIf 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.
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
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
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