Client services — Eben EIO Global

What we deliver

Website design and development

Marketing sites, corporate sites and content-managed sites, designed and built to a written scope with defined acceptance criteria.

We design and build websites that someone other than us can run afterwards.

A typical engagement starts with the content model, not the design. We agree what pages exist, what each one has to say, and who maintains it. The design follows from that, and the build follows from the design.

Accessibility and performance are written into the proposal as numbers, not intentions. We state the target, measure it on handover, and show the measurement.

Content editing is part of the deliverable. If your staff cannot change a page without us, the project is not finished.

What you get

Information architecture and page-by-page content model
Visual design, including a documented colour and type system
Built front end with content editing for non-technical staff
Accessibility and performance targets agreed in the proposal and measured on handover
Deployment, DNS and hosting setup
Handover documentation and an editor walkthrough

How it is engaged

Fixed scope and fixed price where the requirements are settled; staged, with a discovery phase first, where they are not. Either way the proposal states the scope, timeline, acceptance criteria and payment terms before work starts.

Web application development and integrations

Applications with real users and real data, and the integration work that connects them to the systems you already run.

Applications are harder to scope than websites, because the requirements move once people start using them. We plan for that rather than pretending otherwise.

Work runs in short cycles against a prioritised backlog. Each cycle ends with something that runs, so you can see progress instead of reading about it. Change requests go through the process in your agreement: we write down what changes, what it costs and what it moves, and you decide.

Integration work gets the same treatment. We document what we are connecting to, what we assume about it, and what happens when it is unavailable.

What you get

Data model and application architecture
Built application, with automated tests covering the paths that matter
Integrations with third-party services and internal systems
Authentication, authorisation and audit where the application needs them
Deployment pipeline and environment configuration
Runbook covering deploys, backups and failure modes

How it is engaged

Time and materials against a prioritised backlog, in short cycles with a working build at the end of each. Fixed price is available for a well-bounded phase, usually after discovery.

Technical discovery, architecture and implementation

A short, paid phase that turns an unclear problem into a scope, an architecture and a cost you can decide on.

Some projects are not ready to be quoted. The requirements are real but unclear, or there are three plausible approaches and no obvious way to choose.

Discovery is a short, paid phase that resolves that. We work through the problem with you, assess the options, and write down an architecture and a delivery plan with the estimates and the assumptions behind them.

It ends with a decision point. Proceeding with us is one option. Taking the plan elsewhere is another, and the document is written so that is possible. Deciding not to build the thing is also a legitimate outcome, and a cheaper one than finding out later.

What you get

Written problem statement and agreed success criteria
Options assessment, with the trade-offs and the recommendation stated plainly
Target architecture and data model
Delivery plan broken into phases, with estimates and the assumptions behind them
Risk register, including the risks that would stop the project
A decision point — proceed, change direction, or stop

How it is engaged

Fixed price and fixed duration, typically one to three weeks. The output is yours whether or not you continue with us, and the plan is specific enough for someone else to build from.

Ongoing maintenance and support

Contracted upkeep for sites and applications we built, and sometimes for ones we did not — dependency updates, monitoring, fixes and small improvements.

Software that is not maintained degrades. Dependencies acquire known vulnerabilities, third-party APIs change, and the thing that worked at handover stops working.

A maintenance agreement sets out what we keep an eye on, how fast we respond, and how much improvement work is included. We report what we did each period, including the periods where the honest answer is that nothing needed doing.

We will take on maintenance of systems we did not build, after a review. If the review finds we cannot support it responsibly, we say so rather than taking the retainer.

What you get

Dependency and security updates on an agreed schedule
Uptime and error monitoring, with an agreed route for raising problems
Defect fixes within the response times in the agreement
A budget of improvement work each period, spent on what you prioritise
Backup verification, not just backup configuration
A short written report each period covering what changed and what we are watching

How it is engaged

A monthly or quarterly retainer with a defined response time, a defined scope and a stated number of improvement hours. Work outside the scope is quoted separately rather than absorbed quietly.

How an engagement runs

Written proposals

Every engagement is governed by a written proposal or agreement. It sets out the scope, the timeline, the acceptance criteria and the payment terms, and it is agreed before work starts. Verbal scope is not scope.

Acceptance criteria matter more than they sound like they do. They are what turns "is it finished?" from an argument into a check. Where a target is measurable — a performance budget, an accessibility level, a throughput figure — we put the number in the proposal and measure it on handover.

What we need from you

Projects are delayed by missing content and missing decisions far more often than by code. Your side of the agreement is:

Content — text, images, data, by the dates in the plan.
Approvals — a named person who can say yes, and a response time we can plan around.
Access — to domains, hosting, analytics, the systems we are integrating with, and whoever knows how they work.

When something is late on your side we will tell you what it moves, rather than absorbing it quietly and running out of time at the end.

Change requests

Requirements move. That is normal and we plan for it rather than treating it as a failure.

A change goes through the same route every time: you tell us what you want, we write down what it involves, what it costs and what it moves in the schedule, and you decide. Nothing gets built on a conversation, and nothing appears on an invoice that you have not already seen and agreed.

Small changes inside an agreed allowance do not need this ceremony. We will tell you where that line sits for your project.

Warranty and support

After handover there is a defect-correction period stated in your agreement. During it we fix, at no extra cost, anything that does not do what the accepted scope says it does.

What that period does not cover:

New features, or changes to what was agreed. Those are change requests.
Breakage caused by a third-party service changing, by someone else editing the code, or by a dependency we were told not to update.
Ongoing upkeep. Dependency updates, monitoring and improvement work need a maintenance agreement — it is a separate service, with its own response times, not an assumption.

We would rather be explicit about this at the start than have the conversation after something breaks.

Subcontractors

We may use subcontractors for parts of a project — specialist design, a particular platform, or capacity. When we do, we remain responsible for delivery: you have one contract, one point of contact and one party accountable for the result. We will tell you if a substantial part of your project is being done by someone else.

Third-party services

Projects depend on services we do not operate: domain registrars, hosting, SaaS platforms, payment providers, APIs. Use of those is subject to the provider's own terms, and their availability and pricing are theirs to change. We will tell you what a project depends on before you commit to it.

Ownership and licensing

Who owns what is defined in each contract, not by default and not by custom. In outline:

Your deliverables. Ownership and licensing of what we build for you is set out in your agreement. Say what you need — full assignment, an exclusive licence, or something narrower — and we will write it in. We would rather agree this at proposal stage than discover a mismatch at the end.
Our reusable tools. The components, templates, libraries and internal tooling we bring to a project stay ours, unless your contract expressly assigns them. You get the licence you need to use, run and modify your deliverable; you do not get ownership of the toolkit it was built with. This is what makes the next project cheaper rather than starting from nothing.
Your assets. Anything you give us — copy, imagery, data, brand assets — stays yours. We use it to do the work and for nothing else.
Open-source components. We will tell you what a deliverable depends on and under which licences, so you are not inheriting an obligation you did not know about.

The full terms, including liability, confidentiality and termination, are in our terms. Your signed agreement takes precedence over both that page and this one.

Start an enquiry

Tell us what you are trying to build, what is in the way, and when you need it. If the honest first step is a short paid discovery rather than a quote, we will say so.

Tell us about your project