DEV Community: Tsyborg

What does an SSL certificate do for a small-business website?

Tsy — Mon, 05 Oct 2026 14:00:00 +0000

An SSL certificate is what lets a website use HTTPS. In practical terms, it helps a visitor’s browser verify that it is talking to the intended site and encrypts information as it travels between the browser and that site.

For a business website, HTTPS is not an optional decoration. It is the expected baseline for a trustworthy public connection.

What a certificate actually does

When a browser connects to a site over HTTPS, it checks the certificate presented by the server. A valid certificate helps establish an encrypted connection and tells the browser which domain names the certificate covers.

That protects data in transit. It is especially important for contact forms, logins, payment-related handoffs, and any page where a visitor may share personal information.

What SSL does not do

HTTPS is important, but it is not a complete security program.

A valid certificate does not guarantee that:

the business behind a site is legitimate;
the site has no software vulnerabilities;
the content is accurate;
a user’s device is free from malware; or
a form is safe if the underlying application is badly designed.

It solves one specific problem well: creating an authenticated, encrypted connection between a browser and a website.

What visitors see when something is wrong

When a certificate is expired, configured for the wrong domain, or served incorrectly, browsers may show a strong warning before allowing the site to load. That can stop a customer from reaching the business even if the website files themselves are still online.

Common causes include:

a certificate was not renewed;
a new subdomain was added but not covered;
DNS now points to a server with a different certificate;
a migration changed the routing before HTTPS was ready; or
a site is loading insecure resources inside an otherwise secure page.

The browser warning is doing its job. The right response is to diagnose the certificate, domain, and routing—not to tell visitors to ignore the warning.

A practical HTTPS checklist

A business owner does not need to manage certificates personally to ask good questions:

Does the main domain load with HTTPS?
Does the common www version redirect or load correctly?
Is the certificate renewed and monitored before it expires?
Who investigates a browser security warning?
During a site move, is HTTPS tested before the DNS change is considered complete?
Are forms and embedded services checked for mixed-content warnings?

These questions make the responsibility visible. They also prevent a common gap in which the initial site build is complete but ongoing certificate care is unclear.

What managed care should include

A managed provider should explain who is responsible for the certificate, monitoring, renewal, and investigation of browser warnings. It should also explain the process for adding a new domain or subdomain.

As the founder of Borg Sites, I made an SSL-secured connection part of the hosting baseline for every site we build and host. I also built ongoing monitoring and site care into the service because a secure launch is not enough if a browser warning is ignored later. That is why I created Borg Sites for owners who want a human team to handle this responsibility with them, not simply hand over a website and disappear.

The practical takeaway

HTTPS is the quiet connection that lets visitors reach a website without a browser warning and helps protect information while it travels. The best time to clarify certificate responsibility is before a launch or migration—not after a customer sees a warning.

What HTTPS or certificate issue has been hardest to explain to a non-technical stakeholder?

What is DNS—and what should a business owner never change without a plan?

Tsy — Mon, 07 Sep 2026 14:00:00 +0000

DNS is the directory that tells browsers and email systems where to go. If a domain is the address people remember, DNS is the set of instructions that routes each kind of traffic.

That sounds simple, but DNS is one of the few places where a small change can affect a website, email, or a service that depends on the domain. The safe rule is not “never touch DNS.” It is: never change a record until you know what it controls and how you would undo the change.

What DNS does

When someone visits a website, DNS translates a name such as example.com into the destination that serves the site. Different DNS records can direct different jobs:

A and AAAA records direct a name to an IPv4 or IPv6 address.
CNAME records point one name to another name.
MX records tell other mail systems where to deliver email.
TXT records are often used for email authentication, site verification, and other configuration.

A website and its email can use the same domain while being managed by completely different services. That is why a website move does not automatically mean the email records should change.

The records that deserve extra care

For most small businesses, the highest-risk records are the email-related ones:

MX records for incoming email
SPF TXT records that state which systems may send mail for the domain
DKIM records that help mail providers verify messages
DMARC records that tell receiving systems how to handle messages that fail authentication

Removing or replacing those records while changing only the website can interrupt delivery or cause messages to be treated as suspicious. The same caution applies to verification records used by payment, analytics, or identity services.

A safe DNS-change checklist

Before changing DNS, write down the answer to these questions:

What is the one outcome I need? For example: point the website to a new host, verify a service, or add a new subdomain.
Which records are involved? Do not assume every record is connected to the website.
What is currently there? Save a complete record inventory, including the host/name, type, value, and TTL.
Who owns the login? Confirm that the person making the change has authorized access to the registrar or DNS provider.
What is the rollback? Keep the old values so the exact previous configuration can be restored if verification fails.
How will we test? Check the intended page, HTTPS, common subdomains such as www, and the business email flow after the change.

A useful habit is to change only the records required for the task, wait for the expected DNS propagation, and verify before making another change. Changing several unrelated records together makes troubleshooting much harder.

Website changes and email changes are separate projects

A common mistake is to replace a domain’s entire DNS zone with instructions supplied by a new web host. That can overwrite email or verification records that the new host does not know about.

For a website-only move, the goal is usually to preserve the mail-related records and change only the web-routing records. If email is also moving, treat that as a separate migration with its own inventory, sender tests, receiving tests, and rollback plan.

What to ask a managed website provider

A managed service can reduce the day-to-day work, but the owner should still understand the process. Ask:

Who will make the DNS change?
Will the current records be inventoried before anything changes?
How will email-related records be protected?
What does the provider need from the domain owner?
What is the verification and rollback process?

As the founder of Borg Sites, I built the service so we can connect and manage the website side of a client’s infrastructure instead of asking them to operate it every day. That does not mean we treat DNS casually: when a domain also serves business email, I expect the change process to protect the records and services that the owner already relies on. That careful, hands-on approach is why I built Borg Sites.

The practical takeaway

DNS is not mysterious, but it is shared infrastructure. A careful plan protects the website, the inbox, and the other services connected to a business domain.

What DNS change has caused the most unexpected issue in your experience?

Why Tsyborg exists: building practical tools around human needs

Tsy — Mon, 31 Aug 2026 01:08:59 +0000

Before Tsyborg had a name, it started with a practical problem: an educator was trying to find or build resources that would genuinely help students.

Too often, the available options were expensive, poorly built, difficult to use, or simply did not fit the people and situations they were meant to serve. Buying another tool was not always the answer. So the next step was to learn how to build.

That process—teaching oneself new skills, creating the missing resource, and improving it through real use—became the beginning of Tsyborg.

Why the name matters

Tsyborg is pronounced “Cyborg.” The name represents an adaptable idea: technology should change with people, their purpose, and their real-world needs.

It is not about technology for technology’s sake. It is about using the right mix of human judgment, creativity, and practical systems to remove a barrier that is getting in someone’s way.

A busy business owner should not need to become an infrastructure specialist to have a dependable website. An educator should not have to accept a poorly fitting resource because the better option is inaccessible. A person who is not deeply technical should still be able to use digital tools that respect their time.

From one unmet need to an organization

Tsyborg is growing as a family of human-centered products and services rather than as a single one-size-fits-all offering.

The organization starts with a need that is concrete enough to understand:

What is hard, costly, confusing, or unavailable today?
Who is carrying that burden?
What would a more useful and respectful experience look like?
Can the solution be built and maintained in a way people can actually depend on?

The answer may become a focused subsidiary rather than a vague feature list. Borg Sites(https://borgsites.com/), for example, applies that approach to web presence: it provides human-built website design, managed hosting, and ongoing care for people who would rather focus on their organization than operate web infrastructure. BorgMobile is another Tsyborg subsidiary being developed around a different set of needs.

How the approach works in practice

The work follows a simple cycle:

Listen for the real problem. Start with a person’s constraint, not with a tool looking for a use case.
Learn what is missing. Study the existing options, including where they cost too much, create friction, or leave people unsupported.
Build the practical version. Create something clear enough to use, not merely impressive enough to demonstrate.
Carry the responsibility forward. A product is not finished at launch. It needs maintenance, feedback, and honest improvements.
Let each subsidiary stay focused. Different needs deserve distinct products and services, not one confusing brand that tries to do everything.

This is why the company’s story begins with education but does not end there. The lesson was broader: when a necessary resource is too expensive, too complicated, or not built for the people who need it, learning to build a better path can be an act of service.

What Tsyborg is trying to preserve

As the organization grows, a few principles should remain visible:

Human context comes first. A good solution starts with the person using it.
Practical beats performative. The measure is whether it helps someone do real work, not whether it has the longest feature list.
Ownership includes care. Building something creates a responsibility to keep improving it.
Growth should be purposeful. New subsidiaries should exist because they solve a meaningful problem, not because more brands look impressive.

Tsyborg will keep evolving, just as its name suggests. But the reason for building it stays grounded in the original experience: people deserve tools and services that are useful, approachable, and made with their real circumstances in mind.

What is one resource you have needed that was too costly, too complicated, or simply not designed for the people who needed it?

What “built, hosted & handled” means after a small-business website goes live

Tsy — Mon, 31 Aug 2026 01:05:19 +0000

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.