What to expect when you start a software project with us
A plain-language walkthrough of how a project actually runs at Lengix Tech — from the first conversation through to delivery and ongoing support.
Most people have a reasonable idea of how a software project works. Fewer have watched one run end to end from the first message to the day it goes live. This is that, in as much detail as we can give without being boring about it.
It starts with a conversation, not a brief
There’s no template project brief on our side, and if there were, we probably wouldn’t use it. The first call is for us to understand what you actually need, and it’s quite common for what you need to change during that conversation.
A common pattern is someone arriving with a specific feature in mind, and by the end of the conversation realising the feature is the wrong solution to the problem behind it. The feature might be a payment gateway, for example, when the actual problem is that orders get re-keyed by hand between two systems. Both are solvable. Only one of them is the right build.
We’d rather raise that early than build the wrong thing accurately.
Constraints are the useful part
Three things shape almost every decision we make:
- Timeline. What has to be live, and by when.
- Budget. What can realistically be delivered for it.
- Existing systems. What the new work has to live alongside or connect to.
It’s useful to know these even approximately. We aren’t asking for precision — “sometime in the next two quarters” is a perfectly good answer and it tells us plenty.
Planning means writing things down
Once we understand the problem, we put together a plan that sets out what we’ll build, roughly how long it will take, and what it will cost. It won’t be exhaustive. It’s meant to be a document you can read and tell us where it’s wrong.
Work happens in stages
We don’t build for six weeks and then show you something. We build in stages so you can see progress, test things as they come together, and give feedback while changing direction is still cheap. The alternative — a long silence followed by a demo — is how projects go wrong.
Delivery is ready to use
We hand over something that works, not a codebase you need a technical team to run. That means documentation where it’s useful, and a clear picture of what you now own and what to do with it.
Afterwards
We stay available. Most software needs adjusting as the business around it changes, and it should never be the case that you’re locked out of your own system because a contract ended.
If you want to talk about any of this, get in touch.