Get in touch
[email protected]Process design · Project planning · Specification
We start with how the work happens in your company today, design the process that should replace it, and write it down precisely enough to be built from — by your own people or a contractor you choose. We are not that contractor, and that is the point: nothing in the plan is there to keep us busy.
What we do
Each one starts with the same question: what is this costing you today? The technology is a consequence of the answer, never the starting point.
Before the software question, the work question.
What actually happens today: who touches it, in what order, where it waits, and what people quietly work around. Written up as a map you can correct — because a good part of every requirements list turns out to be a workaround nobody has questioned yet.
The way of working that should replace it.
The target process, decided with the people who will have to live in it: what stays manual on purpose, what becomes a rule, what disappears. This step regularly removes more scope than it adds. The cheapest system is the one you no longer need.
The shape of the system, settled before anyone writes code.
What the system owns, where the data lives, who may see what, how a release happens and how a recovery happens. Each decision recorded with the alternative it beat and the trade-off it accepted, in language that still makes sense without us in the room.
Precise enough to be built from, and to be measured against.
Functional requirements, the non-functional ones everyone forgets, interfaces, data, and acceptance criteria attached to each requirement. The document a competent team can turn into working software without having to guess what you meant.
So the offers you get back are actually comparable.
Tender documents drawn from the specification, evaluation criteria agreed before the first pitch, and a technical review of what arrives. We do not bid, and we take nothing from whoever wins — our only interest is that you choose well.
A project you can steer instead of watch.
Phases, decision points, quality gates, and acceptance against the specification. Progress becomes something you can verify rather than something you are told, and problems surface while they are still cheap to fix.
The projects we plan
What we hold to
Values are only worth stating if a client could hold you to them. These are written so you can — and so you know what to ask us about.
We have nothing to sell you at the end.
Our work finishes with a plan, not with an invoice for carrying it out. That single fact sits behind every recommendation in it: no incentive to specify a bigger system, a longer timeline, or a technology that happens to suit us. When we tell you a requirement isn't worth the money, nothing of ours depends on you disagreeing.
The plan is yours, in full.
Process map, architecture decisions, specification, acceptance criteria — handed over as documents you own and can give to anyone. Nothing is written in a notation only we read, and nothing is held back so that the next step has to run through us.
The simplest thing that solves the problem. Sometimes that is nothing.
Most systems fail from too much rather than too little: a platform bought to solve a spreadsheet problem, a microservice architecture for four users. Where the honest answer is a changed process and no new software, we will say so — and that answer costs you a planning fee instead of a project.
Decided in the architecture, not patched on afterwards.
Least privilege, minimal attack surface, no third party without a reason, no data collected because it might be useful later. Security added at the end is a patch; security decided in the architecture is a property of the system. This website follows the same rule — no tracking, no external requests, nothing to leak.
If we can't explain it simply, we don't understand it yet.
You will always know what is being proposed, what it should cost, and which trade-off was accepted on your behalf. No jargon used to sound expert, no architecture diagram deployed to end a conversation. A specification that impresses you without informing you has failed at its only job.
We plan for year five, not for launch week.
A demo can be specified in a week. A system that survives staff changes, audits, load and five years of small modifications is a different discipline, and that is where the money actually goes. We plan for the second one — and we say plainly which parts of it you are safe to postpone.
Measured in what changes, not in documents delivered.
A specification is not a result. We agree upfront what should be different once this exists — fewer manual steps, a quote that goes out the same day, an error that stops happening — and we stay with the project until it is accepted against exactly that. A plan nobody could execute is our failure, not yours.
How a project runs
No phase where you have to trust that things are going well. Each step ends with a document you can read, check and disagree with.
The shape a specification aims at: rules in one place, one source of truth, and operations designed in from the start rather than discovered afterwards.
We follow the work, not the org chart: what happens today, who touches it, how long each step waits, and which parts exist only to compensate for another part. Nothing is proposed at this stage. The goal is a description you read and recognise as your own company.
A written map of how the work runs today, precise enough for you to correct.
Then the decisions, in the open: which process replaces the current one, what the system must own, where data lives, who may reach it, and what deliberately stays out of scope. Every choice is recorded together with the alternative it beat, so it can be revisited later without archaeology.
The target process and the shape of the system, with every trade-off named.
The decisions become a document someone else can work from: requirements, interfaces, data, acceptance criteria, and answers to the questions a bidder would otherwise raise three weeks in. If you intend to tender, this is what goes out.
A specification precise enough to quote against, and a realistic cost range.
While it is being implemented we stay on your side of the table: checking what arrives against the specification, keeping the decision log current, and naming drift early rather than at the deadline. The people doing the work are yours or your contractor's; the standard they are held to is the one you agreed.
Acceptance against the plan, instead of against whatever happened to arrive.
Technology we specify in
The vocabulary a specification is written in is deliberately mainstream, because that is what keeps your options open: easier to hire for, easier to hand to a different contractor, and still supported in five years. And where a choice can stay open, it stays open — the document states what has to be true, not which product to buy.
Application
Data
Infrastructure
Operations
About
Synix Solutions is a small team that plans and specifies IT projects. We stop deliberately before implementation: the moment one company also sells you the delivery, every estimate, every requirement and every technology choice carries an interest that is not yours. Keeping those two apart is the whole value of the arrangement.
We take on work we can be accountable for. If a project needs a capability we don't have, we say so — hearing that from us is cheaper for you than paying us to learn it.
Questions
Answered here so you don't have to book a meeting to find out.
Your own people, or a contractor you choose. The specification is written so that decision stays yours, and so competing offers can be compared line by line. We don't bid for that work ourselves, and we take nothing from whoever gets it.
You can, and for small, well-understood work it is often the pragmatic choice. On anything larger it means the party estimating the work also profits from the estimate being generous, and the party defining “done” is the one being measured against it. Separating the two costs a planning fee and buys you a standard that is independent of the delivery.
A map of the current process, the target process, the architecture decisions with their trade-offs, and a specification with acceptance criteria per requirement. If you are tendering: the documents to send out and the criteria to judge the answers by. All of it yours, in formats you can edit.
Planning is a fraction of an implementation budget, and it gets scoped like any other work: the first conversation is free and ends either with a fixed-scope proposal including a price, or with an honest statement that we're not the right fit. Small, well-defined work runs in weeks. Replacing an established process takes months, mostly because deciding is slower than writing.
Usually not, and replacing them is rarely the cheapest answer. More often the work is to connect what exists and remove the manual copying between the parts. Where something genuinely has to go, we will say so — and where it doesn't, we will say that too, even though a replacement would make for a larger project.
Send an email describing the situation in your own words. No brief or specification needed — producing those is the job. You will get either questions back or a suggested time to talk.
Get in touch
No brief required, no sales call. Describe the situation in a few sentences and you'll hear whether a plan is what you need — and if it isn't, we'll say so rather than write one.
No contact form, on purpose — a form would mean collecting your data on a server. Email leaves it with you. The address is in the footer.
