small-business website is not truly “done” when it goes live. Launch is the point when the public can reach it—but it is also when a set of recurring responsibilities begins.
Someone needs to keep the domain connected, make sure the secure connection works, watch for problems, keep backups, handle the underlying hosting, and make routine changes as the business changes. The question is not whether those jobs exist. The question is who owns each one.
The work that remains after launch
Here are the practical responsibilities behind an ordinary live website:
Domain and DNS. The domain needs to point visitors to the right service. A DNS change made carelessly can take a site or email offline, so it is worth knowing who is authorized to make changes and how they are documented.
Hosting and performance. A website needs a reliable place to run. That includes capacity, updates to the hosting environment, and a plan for problems that affect speed or availability.
HTTPS, security, and abuse protection. Visitors should reach the site over HTTPS. The team also needs an answer for routine security maintenance and unwanted automated traffic.
Backups and monitoring. A backup only helps if it is current and can be restored. Monitoring matters because a business should learn about a problem before a customer has to report it.
Edits and ongoing care. New services, new hours, policy updates, and small fixes are normal. A site needs a clear route for requesting and completing them.
A comparison of responsibility models
This is a workflow comparison—not a claim that every provider works the same way. The Borg Sites column reflects the responsibilities described on its public website. The DIY and build-only columns are questions a buyer should ask, not universal descriptions.
| Responsibility | DIY tool stack | Build-only arrangement | Borg Sites’ stated model |
|---|---|---|---|
| Website setup | The owner selects tools and configures the site. | Scope may end when the initial site is delivered. | At Borg Sites, we design and build the site, using a chosen template or a customized build. |
| Domain and DNS | The owner or an internal teammate normally manages settings. | Ask whether the builder documents the setup and stays available for changes. | I built Borg Sites to connect the website and handle its day-to-day web infrastructure, while treating any email-related DNS change with care. |
| Hosting and HTTPS | The owner chooses a host and maintains the account or support relationship. | Verify who owns the hosting relationship after launch. | Every Borg Sites project is hosted on the SSL-secured global edge described on our site. |
| Monitoring, backups, and security | The owner assembles tools and checks that recovery is possible. | These responsibilities vary by contract; ask for them in writing. | I made monitoring, security, backups, and bot/DDoS protection part of Borg Sites’ ongoing care model. |
| Content updates | The owner makes changes or hires someone each time. | Terms, turnaround, and cost should be agreed before launch. | Borg Sites provides a continuing path for updates and ongoing site care after launch. |
How Borg Sites divides the work
I built Borg Sites for people who want a site without becoming the person responsible for maintaining web infrastructure.
The business still provides the vision: what it does, who it serves, what needs to change, and what should be approved. Our role at Borg Sites is to turn that direction into a site, host it, and handle the routine maintenance described above.
That does not mean the owner should ignore their website. A useful working relationship has a clear approval process, current business information, and a way to request changes. It means the owner can spend less time decoding DNS records, certificates, server settings, and monitoring dashboards.
Compare the scope, not only the monthly number
A low monthly hosting price can be misleading if it leaves the owner responsible for setup, security, backups, changes, and problem-solving. On the other hand, a fully managed service can be the wrong fit for someone who wants to run every technical detail internally.
Before choosing any website approach, ask these questions:
- Who changes DNS or fixes a domain connection problem?
- Who confirms that HTTPS and security protections are working?
- What is backed up, how often, and how is a restore handled?
- Who notices an outage or a performance problem first?
- How are ordinary content changes requested, priced, and completed?
- Which responsibilities remain with the business after launch?
I did not build Borg Sites because one managed model is right for everyone. I built it for owners who want a human team to design, build, host, and keep caring for a site instead of asking them to operate the web infrastructure themselves. That is the specific responsibility model behind Borg Sites.
The best option is the one whose responsibilities match the time, skills, and control a business actually wants to keep.
Top comments (0)