Every tool you rent has an open equivalent you can own. Owning it is easy. Running it properly is the work, and that is what we do.

00

The open stack, and what it stands in for.

Chat was one decision. The rest of the working day runs on the same kind of question.

Every tool an organisation uses every day — files, meetings, mail, sign-in, notes, video — has a mature open equivalent that you can run yourself. None of them are experiments. Most of them are what the proprietary product was built to look like.

The pattern is always the same and it is worth stating once: an open engine that thousands of organisations already run, installed and maintained by somebody, on a machine that belongs to you. The engine is named openly on every page here, because naming it is the point. You are not buying a black box with our label on it.

What you are buying is the part that is actually hard: choosing well, installing carefully, keeping it current, and being the person who is called when it breaks.

What this replaces

• File sharing and sync, in place of Drive, Dropbox or OneDrive
• Meetings, in place of Zoom, Teams or Webex
• Chat, in place of Slack or a consumer messenger
• Mail, in place of a hosted mailbox that reads it
• Sign-in, in place of an account with a platform company
• Video and publishing, in place of an advertising-funded platform
• Notes and documents, in place of a suite you rent by the seat
• Passwords and remote access, in place of a subscription vault

What stays the same whichever piece you pick

• The engine is open source and named, never hidden behind a brand
• It runs on your machine or on infrastructure we hold, never on resold tenancy you cannot inspect
• Cost follows the deployment, not the number of people using it
• Data location is a deployment decision, not a contract clause
• You can take it away, and the way to do that is written down first
• Nothing here needs the others: pieces can be adopted one at a time

Not included: a claim that open software is automatically better. It is better when somebody runs it properly. That is the whole service.

01

Files, documents and everything filed under "where did we put that".

Instead of Google Drive, Dropbox or OneDrive. The same habits, on a machine you name.

Nextcloud is the mature answer here, and it is not a toy version of anything. Desktop sync on Windows, macOS and Linux, mobile applications, sharing by link with an expiry, versioning, and an office suite that edits documents in the browser without sending them anywhere.

The interesting decisions are not about the application. They are about where files actually live, how big it is allowed to get, how it is backed up, and who is allowed to share outside the organisation. Those get decided once, deliberately, and written down.

It is also the piece most likely to be adopted first, because the pain it removes is the one everybody already feels.

Install and run

• Nextcloud installed with hardened defaults and a reverse proxy
• Storage on local disk or object storage, sized against real use
• Collabora or OnlyOffice for editing documents in the browser
• Desktop sync clients packaged for your platforms
• Mobile applications, including automatic photo upload where wanted
• Sharing policy: internal only, link with expiry, password, or open
• Versioning and a recycle bin with retention that suits your obligations
• Backups, and one rehearsed restore before anyone relies on it

Wire it into the rest

• Single sign-on, so it is the same account as everything else
• Group folders that follow the shape of the organisation
• Quota policy by group rather than by individual
• Calendar and contacts served to phones and desktop clients
• Migration from a hosted drive, with permissions carried across
• External storage mounted from what you already have
• Talk, for calls inside the same tool, where that suits better than a separate one
• Audit trail for regulated work

Not included: unlimited storage. Disks are finite and the honest conversation about size happens before the invoice, not after.

02

Video meetings, teaching and events.

Instead of Zoom, Teams or Webex. A link, a browser, and nobody asked to sign up.

Two engines, and they are not interchangeable. Jitsi Meet is for meetings: someone shares a link, people click it, nobody installs anything or creates an account. BigBlueButton is for teaching: slides, a real whiteboard, breakout rooms, hands up, polls, and a register of who attended.

Picking the wrong one is the usual mistake. A university that runs everything on a meeting tool ends up building a classroom out of screen sharing; a company that runs stand-ups on a teaching platform spends its life in a lecture theatre.

Both scale further than most people expect, and both do it by adding machines rather than by buying a bigger licence.

Jitsi, for meetings

• Deployment with cascading bridges, so large rooms actually hold
• No account required for participants, by design
• Lobby, password and moderator approval where it matters
• Background blur, noise suppression, several people sharing at once
• Recording, and streaming out to a video platform
• Telephone dial-in and dial-out where people are not at a desk
• Embedding into your own portal or intranet
• Branding: your name, colours and wording

BigBlueButton, for teaching

• Deployment sized for class numbers rather than meeting numbers
• Slide upload with annotation, and a whiteboard people will actually use
• Breakout rooms with a moderator moving between them
• Polls, hands up, and a clear speaking order
• Recording with playback, and a retention policy for it
• Attendance records where the institution needs them
• Integration with a learning platform
• Load testing before the first day of term, not during it

Not included: a promise that video is cheap. Meetings are the most expensive thing on this page to run at scale, and we will say so before you buy the machine.

03

Video and public presence, without the middle.

Instead of YouTube and X. Your audience reaches you without passing through an auction.

PeerTube hosts video and, when several instances follow each other, shares the delivery cost between them. Mastodon does the same for short public writing, on the same federated principle as chat and mail: your address, your rules, still reachable by everyone else.

The reason to run these is rarely ideological. It is that an advertising platform decides who sees you, changes that decision without notice, and puts a competitor next to your video. Neither of these does that, because neither has anything to sell.

The honest cost is reach: nobody is recommending you to strangers. What you get instead is an audience that arrives on purpose and a channel nobody can throttle.

Video

• PeerTube installed with storage sized to the library, not the first upload
• Live streaming, including from a meeting or an event
• Transcoding policy, which is where the cost actually lives
• Federation with instances worth following, and none you do not want
• Embedding into your own site, without a tracker riding along
• Import from an existing channel
• Retention and takedown process, written down before it is needed

Public writing

• Mastodon on your own domain, so the handle carries your name
• Cross-posting from and to the platforms you still use
• Moderation tooling and a policy that a human can actually apply
• Relays, to be findable without buying attention
• A single account across the organisation, or one per person
• Backup and export, because a public archive is a record

Not included: an audience. Running your own platform gives you the channel, not the people on it.

04

Sign-in, and the directory behind it.

One account for all of it. Instead of a login owned by a platform company.

Keycloak is the piece that turns a collection of tools into something that feels like one system. One password, one policy on second factors, one place where an account is created and, more importantly, one place where it is switched off.

It is also the piece that makes leaving any single tool cheap, because the accounts do not belong to the tool.

Most organisations already have a directory. The work is usually joining that to the new tools rather than replacing it.

Set it up

• Keycloak deployed with a realm per organisation
• Second factor: application, hardware key or one-time code
• Password policy that people can live with, and lockout that is not a trap
• A login page that carries your name, not a stranger's
• Session and token policy matched to how sensitive the work is
• Administrative roles, so not everyone is an administrator

Join it to what you have

• Connect to an existing LDAP or Active Directory
• Provisioning so a new joiner appears everywhere at once
• And, more to the point, disappears everywhere at once when they leave
• Group and role mapping that follows the real organisation chart
• Sign-in for every service on this page, and for your own applications
• Federated login with a partner organisation, where that is wanted

Not included: consumer login with a platform account as the primary route. It can be added, but it hands the front door back.

05

Mail that arrives, on infrastructure that is yours.

Instead of a mailbox that is read to sell you something.

Mail is the hardest thing on this page to run properly, which is exactly why most organisations gave it up. The difficulty is not the server; it is arriving in the inbox, and staying out of the folder nobody reads.

That means authentication done fully rather than partly: sender policy, signatures, a published alignment policy, transport security that is required rather than hoped for, and certificates pinned in the naming system itself.

This is also the piece where our own infrastructure is the argument. Every one of those claims can be tested against ave17.com from outside, right now, by you.

Run it

• Mail server with modern authentication, filtering and quarantine
• SPF, DKIM and DMARC set up completely, not half
• MTA-STS and TLS reporting, so transport encryption is enforced
• DANE, pinning the certificate in a signed zone
• Signed zones throughout, so the answers cannot be swapped in transit
• Webmail, and ordinary clients on desktop and phone
• Backup, archiving, and retention that matches your obligations

Keep it arriving

• Reputation monitoring, and something that tells you before customers do
• Reading and acting on the reports large receivers send back
• Sending domain separated from the domain people reply to
• Migration from a hosted provider without losing archives
• Aliases, shared mailboxes and role addresses
• Rate limits and outbound policy, so one compromised account is not a catastrophe

Not included: rescuing a domain that is already on a blocklist through years of bad practice. That is possible, but it is a project, not a setting.

06

The small tools that carry the working day.

Instead of a suite rented by the seat, for the writing nobody files.

Not everything needs a platform. A page two people write at once during a call, a shared list of links, a feed reader that is not selling anything, an internal wiki that survives the person who started it.

These are individually small and collectively where a lot of the day goes. They are cheap to run and each removes a subscription.

They also work best behind the same sign-in as everything else, which is why identity comes first.

Shared writing

• Etherpad for a page several people edit at once, with no account needed
• An internal wiki with real search and a page history
• Templates for the documents that get written repeatedly
• Export, so nothing is trapped in the tool
• Retention, because a draft from four years ago is still a record

Everything else small

• Shared bookmarks, searchable and not sold to anyone
• A feed reader for the sources you actually follow
• Link shortening on your own domain
• A status page for your own services
• Notifications routed to where people are, rather than to more email
• Spellcheck and language tooling that does not send text away to check it

Not included: replacing every small habit at once. These get adopted one at a time or not at all.

07

Passwords, keys and getting in from outside.

Instead of a subscription vault and a consumer VPN.

Two problems that always arrive together: where the organisation keeps its shared secrets, and how people reach internal systems from somewhere else.

A password vault you run yourself is the same product as the one you rent, minus the part where the vendor holds the encrypted blob. WireGuard is a small, well-understood piece of the operating system rather than a client that phones home.

Both matter more once the rest of this page exists, because a self-hosted estate with weak access is worse than a hosted one with strong access.

Secrets

• Vaultwarden deployed with the organisation model in mind
• Shared collections by team, personal vaults kept personal
• Emergency access, so a locked vault is not a single point of failure
• Browser and mobile clients, and a policy people will follow
• Rotation for the credentials that matter
• Separation between human passwords and machine secrets

Reaching in

• WireGuard with per-person keys and a real revocation process
• Split routing, so only what should go through the tunnel does
• Access to internal services without exposing them to the internet
• Configuration by QR code for phones
• Kill switch, and honest behaviour when the tunnel drops
• Auditing: who connected, from where, and when

Not included: a consumer VPN service for getting round regional restrictions. This is remote access to your own systems.

08

Monitoring, backup and the boring part that decides everything.

Someone has to notice on a Tuesday, before the person who uses it does.

The difference between a self-hosted estate that works and one that becomes a cautionary tale is entirely here. Not the installation. The six months after it.

That means measurements that mean something, alerts that fire before people notice rather than after, backups that have actually been restored at least once, and upgrades rehearsed somewhere safe.

This is the least visible part of the work and the only one that is not optional.

Know what is happening

• Metrics collection across every service on this page
• Dashboards that answer a question rather than fill a screen
• Alerts with thresholds set against real behaviour, not defaults
• Log collection, retention and search
• Uptime checks from outside your own network
• Certificate expiry watched, so it is never noticed by a visitor
• Capacity trends, so growth is planned and not discovered

Survive things going wrong

• Backups with a stated recovery point and recovery time
• Off-site copies, encrypted, with the key held by you
• A restore actually performed and timed, then written down
• Staging that mirrors production, so upgrades are rehearsed
• A runbook per service, written for whoever is on duty
• Scheduled maintenance windows with the work stated in advance
• An honest incident note afterwards, including the ones that were our fault

Not included: a 24-hour on-call rota. Response times are counted in working hours, as stated in the support section at /open-stack/F.

09

Assessment, design and the honest recommendation.

Sometimes the answer is that you should not do this, and hearing that early is worth money.

A lot of this work starts as a question rather than a project: we are paying too much, or the contract renews in March, or somebody asked where the data actually is and nobody knew.

The first piece is usually an assessment: what you run now, what it costs, what obligations apply, and what would genuinely improve if it moved. That produces a document you can take to whoever decides, including the parts that argue against moving.

Then design, then build, then handover. The last one matters most. The goal is an estate your own people can run, not a dependency with our name on it.

Look before moving

• Audit of what you run, what it costs and what it is tied to
• Where the data is now, in fact rather than in the contract
• What obligations apply, and which are actually met
• What would improve if it moved, and what would get worse
• Total cost over three years, both ways, with the labour counted
• A written recommendation, including "stay where you are" where that is right
• Risk register with the awkward items named rather than softened

Then build it

• Architecture and a decision record, with rejected options kept
• Staged migration with a rollback that is real, not theoretical
• A pilot group before everyone, always
• Training for the people who will run it, not just those who use it
• Runbooks and a named owner for every component
• Custom development where a gap genuinely needs closing
• A review some months later, when the honeymoon is over

Not included: a recommendation shaped by what we would be paid to build. If the answer is a product you already have, that is the answer.

start

Start with what it costs you now.

• The useful first message is not "we want to self-host". It is what you pay today, what renews and when, how many people it has to serve, and what obligation is driving the question.
• You get back an assessment of whether moving is worth it, what it would cost over three years counting the labour, and a plain note on the parts we would leave exactly where they are.

Write to

hello@ave17.com

About

Open infrastructure

Not included: a fixed quote from a first message. An assessment is a piece of work, and it is priced as one.

A

The whole stack, and what each piece stands in for.

Twelve pieces of the working day, the open engines behind each, and the thing each one replaces. Named plainly, because the naming is the point: you can look every engine up, find who else runs it, and check it is not a private fork with our label on it.

Not included: a claim that every column is a like-for-like swap. Some are better, some are rougher, and the differences are on the individual panels.

B

How a project runs.

Six stages. The first one often ends with a recommendation not to proceed, and that is a successful outcome rather than a failed sale.

Not included: a fixed price before the assessment. Scope comes first, always in that order.

C

When not to do this.

Six situations where self-hosting is the wrong answer, and what to do instead. Any supplier who cannot name these is selling rather than advising.

You are two people

Below a handful of users the maintenance costs more than the subscription it replaces. Buy the product. Come back when the headcount or the obligation changes.

Better answer: a hosted service, and spend the saved effort elsewhere.

Nobody will own it

Self-hosting fails when it is one enthusiast's side project. The failure is never technical; it is that the person leaves and the estate rots.

Better answer: do not start until an owner is named and has the hours.

You need one specific proprietary feature

If the work genuinely depends on a feature only one product has, no amount of principle replaces it.

Better answer: keep that one product, move everything around it.

The deadline is next month

Migration takes longer than installation, and rushing it is how people lose trust in the whole idea.

Better answer: renew once more, move deliberately, cancel with notice.

You are chasing a certification you do not have

Running software yourself does not confer compliance. It moves the responsibility onto you.

Better answer: understand the obligation first, then decide who should carry it.

It is only about money

Some of this is cheaper. Some is not, once the labour is counted honestly.

Better answer: ask for the three-year comparison with the hours included, and read the total.

Not included: an argument that the proprietary option is always worse. Frequently it is the right call, and we will say so.

D

Under your own name.

Everything here can be delivered so that nothing on the screen mentions us.

Your name on the front

Login pages, applications and the address people type all carry your organisation, not ours. Nothing on the screen says who built it.

Your colours and wording

Themes, icons, first-run text and the wording of errors, adjusted to match what your people already use.

Published as you

Mobile applications released under your own developer account, so the store listing is yours and stays yours.

Your domain throughout

Every service on its own name under your domain, with certificates and mail authentication to match.

Documented as yours

Runbooks and user guides written in your voice, ready to hand to your own support desk.

Quiet by arrangement

We do not list clients by name, and nothing here will ever say who you are without you asking for it.

Not included: pretending your organisation wrote the software. The engines stay open source and their licences travel with them.

E

What it costs.

Move the numbers and watch the total. Nothing is sent anywhere; this runs in your browser and is an estimate, not a quote.

Setup, once

590 EUR

Engineering outside scope

110 EUR an hour

An assessment

from 3 days at 110 EUR an hour

Above 1000 users

the ladder stops and we quote

No VAT is added: we are not registered for it, so the figure shown is the whole figure.

Setup is charged once; everything else is monthly. Unusual constraints are scoped before they are priced.

Not included: a fixed quote from a first message. Scope comes before price, always in that order.

F

What support covers, and what it does not.

Two levels. What each one covers is written down, and so is what it does not.

Working hours, Monday to Friday, excluding public holidays: a request sent on Friday evening is answered on the next working day. Three separate asks in one message count as three requests.

Covered

• The server is down, unreachable or returning errors
• A component that was installed as part of the deployment has failed
• System-level trouble: disk, memory, certificates, backups
• Reconfiguration you ask for: add a component, change a policy, adjust a limit
• Upgrades, and anything that breaks during one

Not covered

• General questions about how the underlying open software works
• Writing your own bots or application services
• Why a third-party component behaves the way it does — its own authors answer that better than we can
• A third-party component breaking after its own upstream changes
• Distribution upgrades of your operating system, on your own machine
• Advice on building a business on top of the software

Not included: a 24-hour rota. Response times are working hours, and they are stated rather than implied.

G

What we can reach, and what we cannot.

The uncomfortable half first, because a page that claims no access at all is not telling the truth.

What we can reach

• Any file on a server we maintain — maintenance runs over SSH with root
• Anything stored unencrypted, including data relayed from other networks, which by their own design cannot be end-to-end encrypted
• Database contents, logs and backups of the deployment
• Account metadata: who exists, when they connected, which devices they hold

What we cannot reach

• The content of end-to-end encrypted rooms — the keys live on the devices, not on the server
• Anything on a machine we were never given access to
• Backups are encrypted with a key you keep. While we administer the machine we have access to the data itself. After our access is revoked we cannot read the backups
• Any deployment after handover, where access has been withdrawn

What we wrote ourselves

• The configuration management that builds and maintains every deployment
• The monitoring and alerting that watches it afterwards
• Matrix client selection, theming and integration
• The backup and restore tooling, including the part that tests the restore
• Everything else on a deployment is third-party open source, named openly on the service pages

How to check, rather than believe

• Logins and program starts are recorded in the audit log on your own machine
• Ask for access to be withdrawn between pieces of work; it is a normal request
• Run the audit framework and watch at the system-call level
• Verify the infrastructure claims yourself. Public tests and instructions are in the section "Where it runs, and how to check without asking us." at /open-stack/H.

Could and does are different things. The access exists to keep a server running and to repair it when it breaks. It is used for nothing else, and the way to hold us to that is the log, not our word.

Not included: a claim of zero access. Maintaining a server means being able to reach it, and pretending otherwise would be a lie you could catch.

H

Where it runs, and how to check without asking us.

Most operators end this section at "servers in the EU". Everything below can be tested from outside, by you, without asking us.

Run the tests yourself

• internet.nl — independent tests for both the site and the mail of any domain
• DNSViz — walks the DNSSEC chain and shows every signature
• Hardenize or an equivalent — one page covering DNS, mail and web posture
• An SSL report against the host — certificate, chain, protocol support
• Point any of them at ave17.com. We are not asking you to take the claim on trust.

None of this makes a chat server secure on its own. It shows how the company is kept, which is the part you can verify before you have signed anything.

Operational controls are documented and can be checked by you.

I

How to leave.

The exit is designed at the start. An operator who makes leaving awkward has told you something about the rest of the arrangement.

You own the identity

The server name is your domain. Whoever operates the machine, the addresses your people hold do not change hands.

You get the machine, not an export

A deployment is a database, a file store and a configuration. All three are handed over as they are, not converted into a farewell archive.

The configuration is readable

Deployments are versioned and reviewable. Your next engineer can read how it was built instead of guessing.

Handover is a service, not a penalty

Runbooks, a walkthrough and a named owner for each component. Priced as work, at the ordinary rate.

Access is withdrawn on request

Keys removed, sessions ended, and the removal visible in your own logs.

No exit fee, ever

There is no charge for leaving and no notice period dressed up as one.

This is also the honest answer to lock-in. The protocol is an open standard: another operator can pick your deployment up, and several exist. That is the point of not owning the protocol.

Not included: free labour. Handover is work and is charged as work — but nothing is charged for the act of leaving.

J

Who you are dealing with.

Who you are dealing with, and the paperwork that goes with it.

Write to

hello@ave17.com

About

Open infrastructure

Not included: legal advice. This states our own position; your obligations are yours to take advice on.

K

The questions that actually get asked.

Not an introduction. These are the eight questions that come up once somebody is seriously weighing this, answered the way we would answer them on a call. Every answer is somewhere above in longer form.

What is lock-in, exactly, and why is it a board-level risk rather than a technical one?

Lock-in is the gap between what leaving would cost you and what staying costs. It is a board-level question because it decides your negotiating position at every renewal: a supplier who knows the exit is expensive does not have to be reasonable, and the price of that is paid every year rather than once. The engines here are open, the formats are defined in public, and the exit is designed at the start, which is what moves the negotiation back.

Is open source actually cheaper?

The software is free and the operating is not, so the honest answer is that it is cheaper above a certain size and dearer below it. What changes is the shape: a licence bill grows with your headcount whether or not the head uses it, and a machine costs what a machine costs. When not to do this is a section of its own on this page, and it is there because the answer is sometimes no.

Who fixes it at two in the morning?

Standard support answers within two working days; priority support within eight working hours. Support is provided in working hours under clause 6 of the terms.

What happens to us if you stop trading?

A deployment on your hardware remains yours. Configuration, operating documents and credentials are handed over during the work, so another operator can maintain the open systems.

Do we have to hire somebody to run this?

No, and that is the arrangement most of this page describes. What you do need is one person on your side who owns the thing: not to operate it, but to decide about it and to be the person we ask. Where nobody owns it, the project fails for reasons that are never technical, and that is the one condition under which we would turn the work down.

Is our data actually safer on our own machine?

Safer from one set of risks and exposed to another. On your own machine nobody else has an account on it, the disks are encrypted and the access is yours to grant; against that, patching, backups and the restore you have never tested are now yours to worry about, and that is what the maintenance is for. What we can and cannot reach is a section of its own above, and it is written so you can check it rather than believe it.

Can we move only part of it?

That is the usual shape. Most estates have one thing that hurts and a lot that is working, and moving the working part is how a migration acquires a reputation. Bridges exist so that the people who are not moving can still be reached, which is often what makes a staged move possible at all.

How long does it take?

The installation is days and the migration is the project, so the honest answer depends on the estate and we will not put a number on it before reading yours. What we will do is name the awkward stage rather than bury it, and put a rollback at every step. A deadline next month is a reason to renew once more and move deliberately.

Not included: a promise that every answer here survives contact with your estate. Some of them will change once we have read it.

L

What is agreed in time.

The support section at /open-stack/F says how quickly we answer. These are the other periods, each with the clause it comes from, so a reader weighing this can check the contract rather than take the page for it.

Before anything starts

An order becomes a contract when we confirm it in writing, and anything said before that is an estimate. Setup begins once the first invoice is paid and you have provided what the deployment needs: a domain, access to the machine where it is yours, and any directory we are asked to join. Clause 4.

A support request, standard

2 in 30 days, answered within 2 working days, included with the machine. Working hours, Monday to Friday, excluding public holidays: a request sent on Friday evening is answered on the next working day.

A support request, priority

4 in 30 days, answered within 8 working hours, at 199 EUR a month. The same working hours. Anything past either allowance is charged at 110 EUR an hour.

An invoice

Payable within 14 days. Setup once before the work begins, maintenance monthly in advance, and work outside the agreed scope quoted before it starts and invoiced when it is done. Clause 5.

A price change

At least 30 days before it applies to you, and never to a month already invoiced. Clause 5.

A change to these documents

At least 30 days before a material change applies, and you may end the contract before it takes effect. The date a version came into force is printed on the document, with every earlier date listed under it. Clause 14.

Notice to stop

1 month in writing, either way. No reason is required and there is no exit fee of any kind. Clause 13.

A breach

Either side may end it at once where the other commits a material breach and has not fixed it within 14 days of being told. Clause 13.

Your data after you stop

Personal data we hold for you as processor is deleted within 30 days of termination, sooner if you ask, unless the law requires us to keep it. Clause 13.

Cancelling as a consumer

Where you ordered as an individual rather than as an organisation, 14 days from the day the contract is made, and the refund within 14 days of your telling us, less the value of any work you asked us to begin inside the window. Clauses 4 and 5a.

Start and delivery dates are agreed in the written scope before the first invoice. Support is counted in working hours under clause 6 of the terms.

Delivery dates are agreed in the written scope for your project.

M

If it does not suit.

Panel C is the case where we would tell you not to do this at all. This is the other three cases: you decide against it, the work is not what was agreed, or something breaks.

If the answer is not to proceed

An assessment that ends in stay where you are is a finished piece of work, and the invoice is the same as one that ends in a build. That is the outcome we are paid for rather than the outcome we prefer, and it is why the assessment is priced small enough to commission before anyone is committed.

If the work is not what was agreed

Where you ordered as a consumer the Consumer Rights Act 2015 requires it to be carried out with reasonable care and skill and lets you require the work to be done again, or the price reduced; no contract can take that away and clause 5a says so. Where you ordered as an organisation, clause 12 limits our total liability in any twelve-month period to what you paid us in it, and nothing above that figure is promised.

If you want to leave

1 month's notice, either way, and the act of leaving costs nothing. You get the deployment as it stands — database, file store and configuration — rather than a farewell export, and access is withdrawn on request. Handover work is charged at 110 EUR an hour; leaving is not. Clause 13, and the leaving page in full.

If we would be the wrong supplier

Where a mainstream hosted product already does the job, nobody on your side will own the result, or the deciding factor is the lowest price this quarter, we would decline the work. We would rather lose it than find out in month three.

If something is broken

An outage is counted and never charged, on either support level. There is no availability promise behind that and clause 7 says so: what is promised is how quickly we answer, not that nothing will fail.

Every line above is in the terms of service, the data processing agreement or the leaving page, all three published in full before anyone is asked to sign anything. Where one of them changes it changes there first and here second, and the date it took effect is printed on the document.

Not included: a satisfaction guarantee, and no promise that nothing will fail. What is here instead is the statutory position and the contract, both published in full before anybody is asked to sign either of them.

How it works

• A · The whole stack, and what each piece stands in for
• B · How a project runs
• C · When not to do this
• D · Under your own name

Before you buy

• E · What it costs
• F · What support covers, and what it does not
• L · What is agreed in time

Before you trust

• G · What we can reach, and what we cannot
• H · Where it runs, and how to check without asking us
• I · How to leave
• J · Who you are dealing with
• K · The questions that actually get asked
• M · If it does not suit