How We Work With Clients at SmartEdge IT Solutions

Clients rarely choose a development partner on the basis of the technology alone. They choose on the basis of what will happen to them over the next few months. This is a short description of how that works here.

What follows is a description of a working arrangement, and it is worth reading as a description of decisions. Most of what goes wrong on a software project is not technical failure; it is a decision nobody realised needed making, taken by whoever noticed it first, at the point where changing it was expensive. Everything below moves those decisions earlier, which is the short version of how projects run at SmartEdge IT Solutions.

Discovery before commitment

We start by understanding the business, the users and the constraints, before proposing anything. That conversation is where most projects actually get decided, because the request a client describes is rarely the problem they have. Someone asking for a customer portal often has a support-cost problem; someone asking for a redesign often has a conversion problem. This occasionally changes the shape of the project, which is the point. It is cheaper to change direction on a whiteboard than halfway through a build.

In practice this means looking at what exists rather than describing what ought to exist: the current site, the report somebody runs by hand every Monday, the spreadsheet holding the real state of the business. Those artefacts say more in an hour than a requirements meeting does in a morning.

Who needs to be in the conversation

The most useful person in that room is not the most senior one. It is somebody who will use the system every day, because a specification decided by someone who has never done the task is a specification for a task nobody has. Alongside them, whoever approves the work and whoever will operate it. It turns difficult only when the person approving will not be there to answer questions in week six.

What discovery ends with

A written summary, sent back before anything is proposed: the problem as we understood it, the users, the constraints, and what the project should not do. Somebody will disagree with part of it, and that disagreement is the most valuable output of the stage. Our appraisal and discovery work exists for organisations who would rather have that conversation on paper.

A written scope, not a verbal one

Every engagement begins with a written scope covering what is included, what is excluded, the approach and the timeline. If a requirement is not in the scope, it is not committed, and neither side has to rely on recollection of a conversation six weeks later. The exclusions matter more than the inclusions, and clients who push back on them at the start are usually the ones who appreciate them later.

The scope answers four questions: what will be built, what will deliberately not be built, what it depends on, and how we will know it is done. It carries a version number, because a document that changes without one is why two people quote different figures. A correction in the first week costs an email; the same correction in the seventh costs a change request.

What counts as done

Nothing is finished until it has been checked against the criteria in the scope, in an environment resembling the real one, and used by somebody who did not build it. That is what testing and quality assurance is for, attached to the definition of done rather than left to a phase at the end, which disappears first when a date gets tight.

A defect is one of four things: blocked, producing a wrong result, unusable on something we said would work, or cosmetic. Agreeing the category before anybody is annoyed prevents small observations turning into a dispute about acceptance. And a dated list of known limitations means a gap found in week four stays identified in week twelve.

Where we will push back

We will say when a request will not achieve what you are expecting, and we will say it early. That covers the small version, such as a feature that sounds simpler than it is, and the large one, such as a rebuild that is not the problem. We have talked clients out of projects. It costs us the work and occasionally earns the next one, and it is cheaper than discovering the mismatch after the invoice.

Not every pushback is about money. A reporting screen that looks like a spreadsheet export is usually three requirements wearing one coat. A rebuild will not fix an enquiry form that is slow because it demands six answers before it accepts an email address, and that is diagnosable in an afternoon of looking. At SmartEdge IT Solutions this happens before anything is signed, the only point at which it is cheap.

What happens if you disagree

We say it once, in writing, with the reasoning attached. You are entitled to overrule us and we will build it your way; what we will do in the same conversation is say what we expect to happen, and record it as a decision with an owner. That is not hedging. It is so nobody is surprised in six weeks, and so that if it turns out badly the decision was shared rather than disputed.

What we will not do is agree to a deliverable we do not believe works, quote a date before the scope exists, or promise an outcome that depends on something outside our control.

Visibility throughout

You see progress as it happens rather than in a final reveal. Work in progress is shared, decisions are recorded with their reasoning, and if something is going wrong you hear it early. Problems found late are the expensive ones, both in money and in the trust that makes the rest of the project workable.

One point of contact on each side

One named person on our side and one on yours who can decide without checking with a committee, with a wider group kept informed rather than consulted on everything. Several decision makers is not a problem to be solved; it is a thing to be routed around, and the routing is our job. A question sent to five people comes back with five answers and none authoritative.

What a useful update contains

Four things, in order: what has been finished, what is being worked on, what is blocked and who it is waiting on, and any decision taken this week with the reason for it. Not a report whose summary line reads that everything is on track, because that sentence is written to avoid a conversation.

We would rather bring you something early than wait until we have a solution to present. A week of unexplained silence is a signal in itself, and the explanation should come from us.

The decisions, and who makes them

Most friction on a project is a decision nobody knew had to be made. Three groups of decision exist, and the useful thing is to say which group a question falls into before it arrives.

• Technical decisions inside the agreed scope: the framework, the data model, the hosting approach, the shape of the code. We make these, write down the reasoning, and revise them when we learn something better.
• Decisions about scope, priority and money: what gets built first, what gets cut, what the budget buys. These are yours, and we give you the consequences of each option rather than a recommendation dressed as a fact.
• Decisions needing a third party: hosting terms, what a payment provider permits, what a legal review concludes. We say what we need; the relationship stays yours.

Record the reasoning, not just the outcome. In three months nobody remembers why the simpler option was chosen, and the next person reads it as an oversight, which is how a settled question gets reopened for no reason.

Where a technology is newer than the team, or interesting rather than necessary, we say so and let it be chosen deliberately instead of drifted into. The point is that the reasoning is written down and the way out of it understood beforehand. How we approach new technology is a longer conversation, but novelty should be an argument rather than a habit.

What we need from you while we build

The most common cause of a slipped date is not technical difficulty. It is content or a decision that was due on a Friday and arrived the following Wednesday, against a plan agreed two months earlier. We plan around that from the beginning.

The five things we ask for

• Access from the first day to the accounts and environments the work touches: hosting, domain, analytics, code repository, and the third-party services in the chain.
• Decisions inside an agreed window. Most are small, and a week of silence on a small one stops work across a large area.
• Content on a schedule: copy, photography, product information, prices. Content delays more projects than code does, and it is almost never the developer’s fault.
• One person who reviews and approves. Not everybody has to approve everything, but somebody has to say yes on the day it is asked.
• Honesty about priorities, including when one changes. A late admission costs far less than a silent one.

A weekly slot for questions, however short, saves a great deal of time. Most delays come from questions nobody asked until the answer was needed.

After launch

Support after launch is a separate conversation, and much easier to have before anybody is annoyed. What is covered, for how long, at what response time, and what counts as a new requirement rather than a fault are all worth putting in writing. That last distinction is where the arguments come from: ongoing support and maintenance is scoped like anything else we do.

What changes during a project, and how that is handled

Something always changes. A requirement turns out to be bigger than expected, an external system behaves differently than its documentation says, or a deadline moves. None of those are failures. What matters is that they are raised while there is still time to do something about them, and that the effect on cost and date is stated rather than absorbed quietly.

The mechanism is deliberately dull. A change is described in writing, priced or estimated, and accepted before work starts on it. A correction to something the scope already covers is absorbed and mentioned in the next update rather than invoiced, while anything adding capability is a change. Nobody absorbs a change silently and explains it later; once that happens, the fixed price stops meaning anything.

Urgency does happen. A deadline moves and the date matters more than the margin, so the answer is to work out what to cut rather than what to compress. There is nearly always a smaller version of a feature that still meets the deadline, and finding it is our job.

Handover as a stage, not an event

Documentation, credentials and training are planned during the build rather than assembled at the end. The final handover is a conversation with the people who will run the system, not a file transfer, and it is scheduled while the work is still fresh enough to explain properly.

That means documentation written while the decision is still in somebody’s head, by the person who made it, and a record of what is still open. Credentials are handed over in a way both sides control, with account ownership made explicit. What gets explained is the business flow and the reason for its shape, not the internal structure of the code.

A handover session where the people who commissioned the work are absent is a handover that has not worked. The person who approved the budget and the person who will operate the system are frequently not the same person, and the gap between what each was told is worth closing in one session. The deployment and launch work is planned around that conversation.

What it costs and how we charge

Prices are fixed for a defined scope, and a change to that scope is quoted before it is started rather than added to an invoice afterwards. Where a project genuinely cannot be scoped in advance, we work in short stages with a decision point at the end of each one, so the commitment is always a stage rather than the whole thing.

The part worth stating plainly is what sits outside the number, because these are the lines that surprise people. Hosting and domains. Licence fees for software bought rather than written. Third-party subscriptions for messaging, payments or storage. Content production, if the project needs it. And the support window after launch, agreed separately rather than assumed to be unlimited.

Nothing is quoted without an agreed scope behind it, and nothing is billed as an extra without a number agreed first. Where work is charged by time, the rate and any cap are in writing before it starts. The reasoning is arithmetic rather than caution: a number that moves later is worth less than a slightly larger one that holds.