Most backup setups have never been tested. What to back up, how often, where to keep it, and the restore drill that tells you whether any of it works.
·5 min read
Almost every business we look at has backups. Very few have restores.
The distinction is not pedantic. A backup is a file you hope is good. A restore
is a demonstrated ability to get your business running again. Organisations
discover which one they have on the worst possible day, and the discovery is not
usually a happy one.
The failures we actually find
These are not hypothetical. In roughly this order of frequency:
The backup runs but contains nothing useful. A dump of an empty schema, or a
container that was rebuilt so the job now points at a fresh database. The job
exits zero every night, which is why nobody noticed.
Backups exist only where the data does. Same server, same account, same
region. That covers disk failure and nothing else. It does not cover a deleted
account, a bad migration replicated everywhere, or ransomware.
Nobody knows how to restore. The person who set it up left. The runbook is
“ask Dave.” Dave works somewhere else now.
The restore takes longer than the business can survive. A twelve hour
restore is a real backup and an unacceptable answer if you take orders online.
Retention is too short to matter. Seven days of backups does not help with
corruption noticed after three weeks, which is the common case, because slow
corruption is quiet.
What to back up
More than the database, though the database is the part people remember.
The data itself. A logical dump plus, for anything meaningful, continuous
archiving so you can restore to a point in time rather than to last midnight.
The schema, separately. You want to be able to inspect structure without
restoring a full copy.
Uploaded files. Documents, images, attachments. These usually live outside
the database and get forgotten, and they are frequently the part that cannot be
recreated.
Configuration and secrets, safely. Not in the same place as the data, but
somewhere. A restored database with no idea how the application connects to it
is a slower outage, not a shorter one.
Two numbers that decide everything
Before choosing tooling, write down two numbers. They convert an abstract
argument into a budget.
How much data can you afford to lose? If the answer is a day, nightly dumps
are fine. If the answer is five minutes, you need continuous archiving, and that
is a different cost.
How long can you be down? If the answer is a day, a dump in object storage
is fine. If the answer is an hour, you need a restore that has been practised
and probably a standby copy.
Most small businesses, asked honestly, land on “a day of data, half a day of
downtime.” That is a comfortable and inexpensive target. Some land on “an hour
and an hour,” and they should know that costs meaningfully more, and decide
deliberately rather than by default.
The rule worth keeping
Three copies of the data, on two kinds of storage, with one copy somewhere else
entirely. It is an old rule from photography and it survives because the failure
modes it covers have not changed.
For a small business running managed Postgres, that is realistically: the live
database, the provider’s automated backups, and your own dump pushed to object
storage in a different account. The third one is the one people skip, and it is
the only one that survives your cloud account being closed or compromised.
Add immutability if you can. Object storage that refuses deletion for thirty
days turns “the attacker deleted the backups” into a non-event, and it costs
nothing extra.
The drill
This is the part that separates the two groups. Once a quarter, someone who is
not the person who built the system restores the most recent backup into a
scratch environment and answers three questions:
Did it restore without errors?
Is the newest record in it as recent as you expected?
Can the application start against it and log someone in?
Write down how long it took. That number is your real recovery time, and it is
usually two to three times what people guess.
A quarterly drill costs an hour and it is the only evidence that any of the rest
is real. If it has never been done, you do not have backups, you have hope with
a cron schedule.
Cheap wins
Alert on the absence of a backup, not just on failure. A job that stops
running silently is the most common failure and the least alerted.
Record the size of every backup. A sudden drop is corruption or a
misconfiguration, visible weeks before you would otherwise notice.
Encrypt before it leaves the machine, so an exposed bucket is an
embarrassment rather than a breach.
Keep one restore document that a competent stranger could follow. Written
when things are calm, not during an outage.
Where this connects to performance
Backups and performance sound unrelated and are not. A database with no
maintenance, bloated tables and no index discipline takes far longer to dump and
far longer to restore. Keeping the database in good shape shortens your worst
day, which is a benefit nobody puts in the business case. The
signs your database is the
bottleneck are worth reading with
that in mind.
If you are not certain your backups would restore, that uncertainty is the
finding. Ask us to run the drill once and you will at least know
which of the two groups you are in.
One email when something new goes up, roughly twice a month. Plain
writing on what software costs and what is worth building. No sequences,
no sales calls, and one click to leave.
Tell us what the problem is. You will get an honest read on whether it is worth building, what it would take, and roughly what it would cost. No pitch deck, no pressure.
Six things: marketing websites, web applications, internal tools, AI systems, AI agents and MCP servers, and database work. Most projects touch two or three of them rather than sitting neatly in one.
Yes. Marketing sites, landing pages and content platforms, built on modern static tooling rather than page builders. They load in under a second and have the technical SEO groundwork done properly.
Yes. Customer portals, dashboards, booking systems and SaaS products. The kind where users log in, data persists and money changes hands, so it has to be right.
Software your staff use rather than your customers. A dashboard pulling numbers from systems that do not talk to each other, a job tracker matching how you actually work, or a scheduled job replacing a report someone assembles by hand every Monday.
Yes, and we will tell you when it is the wrong tool. Retrieval over your own documents, support assistants, document extraction and classification, all built with evaluation and guardrails from the start.
MCP is the standard that lets AI assistants reach your real systems instead of guessing. We build MCP servers that expose your data and tools to Claude and other clients, and agents that carry out multi-step work with permissions and audit trails.
Yes. Schema design, query performance work, migrations between systems, ETL pipelines and reporting layers. Usually called in when the database has quietly become the bottleneck, or the risk.
Not native iOS or Android apps. We build web applications that work properly on phones, which covers most of what businesses actually need. If you need a true native app, we will say so rather than talk you into a compromise.
Related
We design and build the sites and applications we make. We do not do standalone brand identity, logo design or print work. If you already have brand guidelines we will follow them.
Related
Often, yes. The first step is a short paid audit of the existing code and infrastructure, so you get an honest assessment of what is salvageable and what it would cost either way before committing to anything.
Related
Yes, if you want it. You can also take the project and run it yourself using the documentation provided. Both are genuine options and there is no pressure toward a retainer you do not need.
Related
A marketing site typically lands between $3,000 and $12,000 depending on page count and complexity. You get a written fixed price before any work begins, so the number you approve is the number you pay.
Applications and internal tools are scoped individually and most start around $15,000. Once users log in and data persists, you are buying software rather than a website, and it is priced like software.
Related
A single automation or integration is usually $2,000 to $6,000. A proper internal application with its own database and user roles runs $6,000 to $20,000. Anything your operations depend on goes up from there.
Fixed price wherever the scope can be fixed. That means we absorb the overrun rather than you, and it is usually worth the small premium on a first project together. If something changes mid-build you hear about it before the work happens, not on the invoice.
Related
A static marketing site is commonly free to host and stays free at traffic levels most local businesses never reach. A well-built internal tool usually runs $10 to $50 a month. Budget 15 to 20 percent of the build cost annually for maintenance.
Related
Copywriting, photography, ongoing SEO work and third-party subscriptions are the four things most commonly assumed by the client and excluded by the quote. Ours states what is and is not covered explicitly.
Related
Yes, typically a portion up front with the remainder on delivery, or split across milestones for larger projects. The exact split is agreed in the written proposal before work starts.
Related
Rarely page count. Integration complexity, how much the process changes mid-build, and how clean your starting data is. Messy historical data is the single most common reason projects overrun.
Related
Usually. Tell us the number and we will tell you honestly what fits inside it and what does not. That is a more useful conversation than pretending everything fits.
Related
Yes. Scoping conversations and written proposals cost nothing and carry no obligation. We will also provide a written quote for a grant application without charging for it.
Related
Yes, and they are meaningful. Registered charities, non-profits and small local businesses get reduced rates on every service, because a tight budget should not be the reason an organisation is stuck with software that does not work.
Registered charities and the volunteer-run groups that support them, non-profits and community organisations, and small owner-operated businesses including new ventures still finding their feet.
Related
There is no application and no paperwork. Mention it in your first message and the reduced rate is built into the quote you receive.
It depends on the project and the organisation, and you are told exactly what it is before committing to anything. We do not publish a single percentage because it would be either misleading or useless.
Related
Often, yes, and they are widely underused. Google for Nonprofits, TechSoup Canada, community foundations and your existing funders are all worth approaching. We wrote a guide to what is actually available.
If you are small and owner-operated, yes. Ask when you get in touch and we will tell you straight rather than making you guess.
Related
Four stages. Scope: a conversation about the problem, not the tech. Plan: a written proposal with price and timeline. Build: short cycles with something working at the end of each one. Ship and support: deploy, hand over documented code you own outright.
A straightforward marketing site takes two to four weeks from kickoff. Applications and internal tools usually run six to twelve weeks, delivered in cycles so you see something working every week rather than waiting until the end.
Related
Completely. Code lives in your repositories, hosting and domains are registered in your name, and everything is documented at handover. There is no licence to keep paying and no lock-in forcing you to stay.
Related
You keep everything, because it was always in your accounts. Documentation and a clean handover are part of the work rather than an extra, precisely so that another developer can pick it up.
Related
Most of it is at the start, agreeing what gets built. After that, expect a short check-in each cycle to look at progress. The most common cause of delay is waiting on content from the client side, so having copy and images ready helps more than anything else.
Related
Yes, and it is normal. You hear the cost and timeline effect before the work happens, so a change is a decision you make rather than a surprise on the invoice.
Related
Yes. Content is set up so you can change text and images without a developer in the loop, using either a CMS or markdown depending on what suits your team.
Related
Yes, routinely. Send yours over or ask and we will provide one.
Related
Often. Being brought in for a specific piece, or to work alongside an in-house team, is common and works fine as long as the boundaries are clear up front.
Related
A description of the problem. Not a specification, not a wireframe, just what is going wrong or what you are trying to do. Everything else comes out of the scoping conversation.
Astro and Next.js for sites and applications, React and TypeScript on the front end, Node.js and Python on the back, PostgreSQL and MongoDB for data, and Netlify or Vercel for hosting. Chosen per project rather than by habit.
Related
Only when it is genuinely the right answer, which is less often than it is used. For most marketing sites a static build is faster, safer and cheaper to run. For a large store or complex memberships, WordPress earns its place.
Wherever you need it. AWS and Google Cloud both have Canadian regions in Montreal and Toronto, and hosting in Canada is straightforward and usually costs nothing extra. If your customers ask where their data lives, that is worth having a clear answer to.
Related
Usually not. PIPEDA does not require personal data to be stored in Canada, provided you are transparent and the data receives comparable protection. Rules that do mandate it are mostly provincial public-sector rules. Health data and government contracts are stricter, so check those specifically.
Yes. Sites are built to WCAG 2.1 AA, which covers keyboard navigation, screen readers, colour contrast and focus states. It is part of the build rather than a paid extra.
Related
Sub-second loads and 95 or better on Lighthouse are the target, and normally the result. Static output with no render-blocking JavaScript is most of how that is achieved.
Related
The technical groundwork, yes: structured data, sitemaps, clean semantics, fast pages and unique metadata per page. Ongoing content and link building is a different discipline and we will say so rather than sell it.
Related
A static site has no database to breach, no admin login to brute force and no plugins running server-side code, which removes most of the attack surface. Where an application does need those, authentication and permissions are built to hold up.
Related
Usually. If your CRM, accounting package or booking system has an API or webhooks, it can be connected. Integration between systems you already pay for is one of the highest-value things to automate.
Related
Backups you have actually tested, not just configured. Restoring from a backup nobody has ever tried is a plan with an unknown failure rate.
Related
Often not, and we will say so. It is worth it when the task involves unstructured language, the rules are fuzzy, you can tell right from wrong, and a wrong answer is survivable. Fail any of those and something simpler is the better build.
Answering questions over your own documents, extracting structure from messy input like invoices and forms, triaging and routing incoming work, and generating first drafts a human then edits. Those four cover most of the real value.
Related
Chatbots on the front page, which almost nobody wants. Anything needing exact numbers, because models are not calculators. And automating a process nobody has written down, which just scales the confusion.
Related
Less than most people expect. A well-built retrieval system for a small business commonly runs in the tens of dollars a month. Costs balloon from stuffing whole documents into every request and using the largest model for tasks a smaller one handles.
Related
It can, which is why systems are built to answer from your data with sources attached rather than from memory. Anything that matters gets a human in the loop, and evaluation is built in from the start so you know when it works.
Related
A system that takes multiple steps toward a goal without being prompted at each one. Impressive in demos, frequently disappointing in production, and the gap is engineering rather than model quality.
Worth it when your team already uses an AI assistant daily, the information lives in a system with an API, and people ask the same questions repeatedly. Start with one read-only server answering a single question, which takes days and cannot break anything.
Related
It is, when scoped properly. Expose the narrowest set of capabilities that answers the real questions, separate read from write, put approval gates on anything destructive, log every call, and give it its own credentials rather than a shared admin account.
Related
Call, email, or use the contact form. The form asks a few questions up front so the first reply can be useful rather than a request for more information.
Within one business day, usually sooner. If it is urgent, calling is faster than the form.
Related
Alberta, Canada. Work happens remotely with clients across Canada and the United States, over email, video calls and shared preview links.
Related
Regularly. Location has never been a constraint on this kind of work. Being Canadian helps with timezone overlap, invoicing in Canadian dollars and familiarity with the privacy rules, but it is not the deciding factor.
Related
That is the preferred starting point. No pitch deck, no pressure, and no obligation. You will get an honest read on whether the thing is worth building at all.
Related
That is the normal case and completely fine. Describe what is going wrong or what takes too long, and working out the shape of the solution is part of the job.
