Summary
- Ty Cloud resolves to an active French company rather than an untraceable cloud label. France's public company service identifies TY CLOUD, SIREN 841 671 795, as a Vannes-based SAS created in August 2018, with one active establishment, hosting as its principal activity and Yann Eric Guillemot as president. That establishes a contracting identity and local address, but it does not establish the ownership, capacity or resilience of every asset sold under the brand.
- The public service proposition is broad for a small provider: internet access over fibre, xDSL and 5G; private networks; fixed and mobile telephony; web, email and dedicated-server hosting; off-site backup; managed IT; security audits; training; and recovery testing. Ty Cloud also says it owns and operates an eco-designed Tier III data centre in Vannes. Those are specific claims worth diligencing, not substitutes for facility certification, service-level terms, recovery evidence or an order that names the exact hosting site.
- Network records provide harder operating evidence. RIPE identifies TY CLOUD SAS as a French local internet registry, assigns it AS199360 and associates it with the French IPv4 block 193.22.225.0/24. At the observation point, the block was globally visible through a path whose immediate neighbour was Netensia's AS35665, and tycloud.bzh itself resolved inside that block. This shows real network control. One visible IPv4 prefix, no public PeeringDB profile and no IPv6 address on the main website do not, however, prove carrier diversity, route resilience or modern dual-stack delivery.
- Local support is part of the product, not just its tone. Ty Cloud publishes a Vannes telephone number, weekday opening hours, branded remote-support downloads and a claim of seven engineers and technicians. The latest public employment band reviewed was three to five employees for 2023, so buyers should clarify current staffing, employment versus contractors, night and weekend cover, escalation ownership and key-person risk. For important systems, a familiar local number becomes assurance only when response, authority, access and restoration duties are written and rehearsed.
A cloud name with a street address
The most revealing fact about Ty Cloud may be its address. Six Place Albert Einstein in Vannes is not an abstract region on a hyperscale map. It is the address shown by the French company record, the company's legal notice, the RIPE organisation record, the Arcep communications list and the support page. Those records do not merely repeat a brand. They join a legal person, a telephone number, a network holder and a customer contact point to the same location in Morbihan.
That convergence matters because cloud language normally pulls in the opposite direction. It encourages the buyer to think in placeless resources: a virtual machine, an inbox, a backup volume or a fibre circuit ordered through a name. But every one of those products ultimately depends on a contracting company, equipment in a place, network relationships, software permissions and people with enough authority to act. Ty Cloud's public record gives a buyer a plausible starting point for all five. It does not collapse them into one proven whole.
The BTW directory entry provides the stable link to the company. The harder work is to understand what the company controls. France's public company search service identifies TY CLOUD under SIREN 841 671 795. It records a SAS created on August 6, 2018, principal activity code 63.11Z for data processing, hosting and related work, one currently open establishment, and a headquarters established at the Vannes address in May 2020. Its July 2026 response names Yann Eric Guillemot as president and reports the latest workforce band as three to five employees in 2023.
The company's legal notice supplies the same address and RCS number, a capital figure of EUR125,000, VAT number FR55841671795, the same president and the public phone number 02 57 47 02 40. It also says Ty Cloud hosts its own website. A separate company profile derived from French public filings describes the declared activity more fully: hosting equipment and computer data, trading computer equipment, IT advice and services, and wired telecommunications.
This is a better identity chain than a footer containing only a trading name. It gives a customer a company against which to check an order, invoice, insurance certificate and processing agreement. It also narrows an important ambiguity. The commercial name is sometimes presented as Tycloud and sometimes as Ty Cloud, but the legal counterparty is TY CLOUD. A contract should use that legal name, its current registered number and the address that appears in the public record. A customer should not let the warmth of a regional brand stand in for the basic discipline of identifying who owes the service.
What the French record can and cannot certify
Ty Cloud's home page describes the business as an operator "agréée ARCEP", language that can sound in English like regulatory approval. The public record supports operator activity, but not that interpretation. An Arcep decision covering 2019 operator revenue declarations lists Ty cloud under the code TYCL. The current Arcep communications-identifier file, updated in July 2026, still records Ty cloud, the same SIRET and address, code TYCL and an original declaration date of September 5, 2018.
Arcep's own explanation of communications identifiers is unusually direct. The former prior declaration, it says, had no value as approval by the regulator. That declaration requirement was removed after the 2021 transposition of the European Electronic Communications Code, and Arcep no longer issues declaration receipts. It retains communications identifiers for numbering and inter-operator purposes. Arcep also warns that presence in the list does not by itself prove that an organisation is an electronic communications operator, while absence does not prove that it is not. The nature of the activity is decisive.
For Ty Cloud, the surrounding evidence makes the operator claim credible in an ordinary commercial sense. The company offers internet access, private networks and telephony; it appeared in the 2019 service-universal material; its current code remains in Arcep's file; and it now operates an autonomous system. The distinction is nevertheless important. A regulator-associated code is not a technical audit, a service endorsement, a financial guarantee or a certification that a particular fibre circuit has diverse routes. The public Arcep file also marks Ty Cloud as not directly attributed numbering resources in the captured record.
That is not a defect: providers can deliver telephony through resources made available by other operators. It does mean that a buyer should ask whose numbers, switching platform and portability obligations sit behind the ordered telephone service.
This is the first lesson of Ty Cloud's record. Formal identity is valuable because it makes accountability possible. It does not supply all the assurance that marketing language can imply. A procurement team should preserve the useful facts - French company, local address, operator activity, current communications code - while asking a separate question for every service: what does this evidence actually prove about the thing we intend to buy?
Four businesses sit inside the proposition
Ty Cloud's public site groups its work into four lines: operator, hosting provider, managed IT and cybersecurity. Read as a catalogue, that is a broad offering. Read as a control map, it describes four rather different ways in which the company can enter a customer's systems.
The operator page offers internet access over fibre, xDSL and 5G, along with private networks and fixed and mobile telephone services. The page speaks of designing, implementing and maintaining private infrastructure with the customer. That suggests a project and service relationship rather than a simple resale link. It also creates several possible boundaries. The last-mile fibre may belong to a wholesale network. The internet route may leave through an upstream carrier. Mobile service may depend on a host network. Voice numbers and switching may come from another supplier. Ty Cloud can still be the accountable operator for the customer experience, but the order should name those dependencies and say whether Ty Cloud owns the incident from first report to restoration.
The hosting page describes web and professional email hosting, dedicated servers and off-site backup. These products put different responsibilities on each side. Web hosting may include patching of the web platform but not the customer's application. A dedicated server may be a physical asset, a virtual allocation or a managed service, depending on the order. Off-site backup may protect data from a failed production host, yet still share a building, power domain, administrator account or provider with production. The page gives a buyer categories to investigate; it does not publish the retention periods, immutability controls, restore objectives or physical separation that turn backup into recoverability.
The managed-IT page adds fleet management, infrastructure supervision, systems auditing and strategy advice. This is potentially the stickiest part of the relationship. A provider that monitors servers, holds privileged credentials, deploys updates and advises on architecture can reduce the customer's operating burden. It can also become a concentration point for access, knowledge and change authority. The customer needs to know where credentials are vaulted, how administrator actions are logged, which changes require approval, how emergency access works and how those records are exported if the relationship ends.
The cybersecurity page offers awareness training, security audits and recovery-plan tests. Its most concrete description is the use of a mobile IT rack to simulate emergency conditions during recovery testing. That is a more useful claim than a generic promise to make systems secure, because it points toward an observable exercise. But the value depends on the test design. A customer should distinguish a demonstration from a full restore, an infrastructure start from application recovery, and a provider-authored report from independent assurance. The evidence should record the scenario, failed components, data point restored, recovery time, missing dependencies, decision owners and corrective actions.
Together these lines show why Ty Cloud cannot be assessed as a single undifferentiated "cloud". It may be the connectivity provider, host, administrator, security adviser and recovery partner for the same customer. That integration can be efficient, especially for a smaller organisation that does not want four suppliers. It can also place several failure and access domains under one management team. The right response is not to reject integration. It is to make each role visible and ensure the combined service has stronger controls than four disconnected contracts would have had.
The Vannes data-centre claim is specific enough to test
Ty Cloud says it owns and operates its own "digital safe": an eco-designed data centre in Vannes. The home page dates the facility to 2019, calls it Tier III and presents several operating counts: 180 hosted websites, 67 sites served over fibre, 508 telephone lines and 188 professional clients. The hosting page places the data centre in southern Brittany and says it combines performance, security and environmental responsibility.
Those claims are notable because they describe a local physical asset rather than merely a French invoice for foreign capacity. There is also an independent trace of real hosting use. The housing organisation Les Ajoncs identifies Ty Cloud at the Vannes address as the host of its website. A Low-tech Lab report says the collaborative service Kaz is hosted by tycloud.bzh in Vannes and describes liquid-cooled servers as taking six times less space and requiring ten times less cooling energy than conventional fan-cooled servers. That report is not a facility audit, but it is an outside reference connecting a live regional digital service, Vannes hosting and a particular cooling approach.
The next step is to resist turning specificity into certification. "Tier III" has a precise resonance in data-centre procurement. It can refer loosely to a concurrently maintainable design, or it can refer to certification by Uptime Institute for design documents, constructed facility or operational sustainability. Ty Cloud's public pages reviewed for this article did not display an independent certificate number, certifying body, scope or expiry. A buyer should therefore treat Tier III as a provider claim until the relevant evidence is produced. The same applies to eco-design.
Liquid cooling can reduce cooling demand, but environmental performance depends on utilisation, power source, cooling architecture, water use, heat reuse, hardware life, embodied carbon and measurement period. The public pages did not provide a power-usage effectiveness series, capacity figures or an audited carbon method.
That does not make the environmental proposition empty. A small regional facility using compact liquid-cooled equipment may offer a genuinely different design from a conventional room of air-cooled racks. The useful diligence questions are concrete: Which equipment is liquid cooled? What is the cooling boundary? Is heat recovered? What power and temperature data are retained? What is the facility's design and occupied capacity? Which maintenance can be performed without shutting customer equipment down? Which environmental figures are measured rather than modelled?
Physical resilience needs the same discipline. The site reviewed did not state the number of utility feeds, generators, uninterruptible-power modules, fire compartments, carrier entrances or staffed security layers. It did not identify a second Ty Cloud facility for synchronous or asynchronous recovery. An "off-site" backup product could be excellent, but the phrase alone does not say off which site.
A customer with a serious continuity requirement should obtain a location diagram at the right level of confidentiality, evidence of power and network testing, the secondary copy's site and operator, encryption ownership, retention policy, and the result of a recent restore.
Locality makes these questions easier to ask. It may even make a visit possible. But a nearby building is not automatically a separate failure domain, and a tour is not an availability record. The strongest use of proximity is to convert it into inspectable evidence: a facility visit, a witnessed maintenance exercise, a backup restore, a route-failover test and a named person who owns each corrective action.
AS199360 turns the operator story into network evidence
The public internet record supplies a harder anchor than the service pages. The RIPE organisation record names TY CLOUD SAS, country France, organisation type LIR, the Vannes address and the same public telephone number. Local internet registry status means the company has a formal role in receiving and managing internet number resources within the RIPE NCC service region. It is evidence of network administration, not a quality award.
The associated autonomous-system record assigns AS199360, named "tycloud", to that organisation. The ASN was created in March 2023. RIPE's announced-prefix view showed one broadly visible prefix at the observation point: 193.22.225.0/24. The RIPE record identifies the underlying allocation as the French block 193.22.225.0 through 193.22.225.255 and links it to TY CLOUD SAS. A route object ties the /24 to AS199360.
This is meaningful operating evidence. It shows that Ty Cloud is not merely putting its logo on a generic hosting storefront. It has its own ASN, an allocated address block and a route visible to internet observers. The main tycloud.bzh name resolved to 193.22.225.81 during the same observation, placing the company's public website inside its own block. The company therefore appears to use the resources it administers for at least part of its public service surface.
The scale and topology need careful wording. One /24 contains 256 IPv4 addresses, of which fewer are normally usable for ordinary hosts after network design and reserved functions. Prefix count is not a server count, customer count or capacity measure. Addresses may front many virtual services, and large amounts of compute can sit behind a small address pool. Conversely, a routed /24 says nothing about power, storage or application recovery. It establishes an internet routing surface of limited public breadth.
The RIPE BGP observation contained hundreds of collector views, all of whose captured paths reached AS199360 through AS35665 immediately before it. RIPE identifies AS35665 as Netensia SARL. The next visible network in the common path was AS174, Cogent. This suggests that Netensia was the single publicly observed immediate upstream for the prefix at that moment.
It does not prove that Ty Cloud has only one physical carrier or no private backup. Route collectors see advertised paths, not every dark fibre, tunnel, emergency circuit or commercial agreement. A standby connection may be intentionally invisible until failure. Equally, two carrier logos can enter the same duct or converge on the same upstream. The correct procurement question is not "How many providers do you have?" but "Show the active and failover paths for this service, their physical entrances and last successful failover test."
Ty Cloud had no public network entry in the PeeringDB API response for AS199360 at the observation point. That absence is neutral. Small networks often buy transit without maintaining a public peering profile. It does mean that a buyer cannot use PeeringDB to verify exchange participation, facility presence, public capacity or peering policy. Those details should come from a network diagram, upstream letters or test evidence instead.
The IPv6 gap is small on screen and large in implication
The main website returned an IPv4 address but no AAAA record during the technical check. Its public name servers were OVH's dns11.ovh.net and ns11.ovh.net. Arcep's 2025 hosting-provider IPv6 table also listed AS199360 with a 0.0 percent web-accessibility result across the sample attributed to it. These observations do not prove that Ty Cloud has no IPv6 capability anywhere. They do show that dual-stack delivery is not demonstrated by the most visible public surface.
For an ordinary brochure site, that may cause little immediate pain. For an operator and hosting provider, it matters more. IPv6 is not simply a badge for technical modernity. It affects customer architecture, address conservation, inbound reachability, monitoring, security policy, logging, partner connectivity and the cost of postponing migration. A customer deploying new services should ask whether Ty Cloud can provide native IPv6, what prefix size is delegated, whether reverse DNS and route security are supported, whether protection and monitoring cover both protocols, and whether the backup and recovery environment behaves the same way.
The distinction between the company's website and its customer platform remains important. A missing AAAA record on tycloud.bzh is not proof that hosted servers cannot receive IPv6. It is a reason to test the ordered service. A useful trial would provision a dual-stack endpoint, check routing from several networks, validate filtering parity, inspect logs for complete IPv6 addresses, and verify that support can diagnose a protocol-specific failure. That test yields more assurance than either a marketing claim or an external scan on its own.
French control is not one thing
Ty Cloud's strongest commercial appeal is likely not raw scale. It is the combination of a French counterparty, a Vannes facility claim, regional staff and the possibility that data can stay close to the customer. That can be valuable for latency, access to support, contractual familiarity and public-sector or regulated-sector preferences. But "sovereign" and "local" become unreliable when they are treated as indivisible properties.
At least four forms of locality matter. Legal locality asks which company signs the agreement and which law governs it. Data locality asks where primary data, replicas, backups and logs are stored. Operational locality asks where administrators and subcontractors can access those systems. Dependency locality asks which outside services can interrupt delivery, identity, email, monitoring, licensing or support. Ty Cloud's French company record answers the first question. Its site makes a Vannes hosting claim relevant to the second. The public evidence does not answer every instance of the third and fourth.
The company's own public domain illustrates why the layers should remain separate. DNS records placed the website inside Ty Cloud's IPv4 block, which is evidence of direct network use. The authoritative name servers were at OVH. Email delivery pointed to Mailinblack. The domain's sender-policy record referred to Mailinblack, OVH, Microsoft protection, Autotask and Transmail. A Mistral domain-verification string was also present. These records are normal signs of a business combining specialist services. They do not imply that customer workloads use the same suppliers.
They do show that a local provider can have a distributed operational dependency chain even when the web server is in its own address space.
The procurement consequence is straightforward. Data location must be attached to each product and data class, not inferred from the company address. An order for web hosting should identify the production and backup sites. An email service should identify the mail platform, filtering provider, journaling location and administrator access. Managed IT should identify the remote-monitoring and ticket systems, their hosting regions and subprocessors. A backup service should identify replication sites, encryption-key control and deletion timing. Telephony should identify the number holder, switch and call-record locations.
"Hosted in Vannes" is meaningful only when the noun being hosted is explicit.
This is not an argument that every dependency must be French. A specialised filtering or productivity provider may improve reliability and security. The point is that a buyer cannot evaluate jurisdiction, concentration or exit risk without seeing the chain. Ty Cloud's regional identity is most valuable when it becomes the front door to that transparency: one accountable French counterparty that can explain, contract for and manage the external components it uses.
Local support is labour, not geography
Ty Cloud gives support a visible human shape. The website publishes the Vannes number and office hours of 8:30am to 12:30pm and 1:30pm to 6pm, Monday to Friday. Its support page offers branded AnyDesk clients for Windows and macOS, tells the user to provide a one-time identifier by telephone and says the user must accept the connection and can end it. The broader site says seven engineers and technicians are available to apply their expertise.
This is useful evidence of a support mechanism. A customer can see how remote assistance begins, which telephone number to call and when normal office cover is available. That is more accountable than a form with no stated hours or an anonymous chat box. The remote-support instructions also preserve an important consent step rather than implying unattended access.
The workforce evidence introduces a question rather than a contradiction that can be resolved from outside. The company's site claims seven engineers and technicians. The official French company response reviewed in July 2026 reported a three-to-five employee band for 2023. LinkedIn described a company size of two to ten and displayed several named people. These figures refer to different dates and methods. The team may have grown; the seven may include directors, apprentices or contractors; the official band may lag.
A buyer should ask for the current service-team structure, not choose whichever public number is more flattering or more sceptical.
For local-support assurance, headcount is only the beginning. The important facts are coverage and authority. Who watches alerts outside office hours? Is there a separate emergency number? What severity earns a night or weekend response? Can the person answering restart infrastructure, change a route, access the facility, restore a backup and contact the upstream carrier? Who substitutes during illness or holiday? How many people can perform the most sensitive recovery step without relying on one founder or specialist?
A small team can outperform a distant help desk because it has context and direct access. It can also be vulnerable to simultaneous incidents, leave and key-person concentration. The answer is not necessarily a larger team. It can be disciplined rotation, documented procedures, cross-training, an external maintenance agreement and clear escalation to suppliers. The customer needs evidence that the local relationship survives the moment when the person who knows the system is unavailable.
Remote support brings a second set of controls. Branded AnyDesk downloads make the tool easy to obtain, but the customer should still govern its use. Sessions should be initiated through a verified ticket or telephone path, approved by an authorised user, protected with strong authentication, logged, time bounded and removed or disabled when no longer needed. Privileged actions should be attributable to an individual technician. For managed environments, unattended access should have a separate approval, credential and audit design from ad hoc desktop assistance.
The site's published hours also make the support boundary honest enough to question. Nothing in the reviewed pages established a continuous enterprise service desk or a public severity-and-response table. A customer running an important system should not assume that an operator and host is staffed around the clock merely because infrastructure runs continuously. The contract should distinguish office support, automated monitoring, on-call engineering and physical intervention. Each can have a different clock.
Service counts are clues, not denominators
Ty Cloud's home-page counters - 180 websites, 188 professional clients, 67 fibre-operated sites and 508 telephone lines - give the business a recognisable scale. They suggest a provider serving regional organisations across more than one product, rather than a data-centre project with no visible customers. The Les Ajoncs hosting notice supplies one named customer-side trace. The Low-tech Lab report supplies another indirect trace through Kaz.
The counts still lack the denominator needed for assurance. The site does not date each figure on the face of the counter. It does not say how many hosted websites share a platform, how many customers buy only one service, how many fibre sites use diverse access, or how many telephone lines depend on the same switch. Counts can demonstrate commercial activity without demonstrating resilience. In fact, concentration becomes more important as multiple customer services share one facility, upstream or team.
A buyer can turn the counts into useful diligence by asking for ratios and history. How many material incidents affected the facility during the last 24 months? What percentage of backup restore tests completed within target? How many internet circuits have a physically diverse path? What portion of support tickets were answered and resolved within the contracted time? How many services depend on each upstream or platform? How often have customers exercised data export and exit?
Ty Cloud need not publish customer-confidential details to answer. Aggregated service reporting, redacted incident reviews and witnessed tests can show operational maturity without exposing the environment. A small provider may not have the reporting machinery of a multinational cloud, but it can often provide something more direct: a recent maintenance record, the engineer who performed it, the customer impact and the corrective action.
The automation surface remains mostly behind the service
Ty Cloud describes managed services and supervision, but the reviewed public pages do not expose a detailed self-service cloud interface, public application-programming interface, infrastructure-as-code provider, status history or technical knowledge base for customers. That does not mean those facilities are absent. The public proposition is plainly relationship-led and tailored. It does mean that a buyer interested in repeatable enterprise operations must ask to see the control surface rather than infer it from the word cloud.
This matters because automation determines how much of the service can be inspected, reproduced and moved. A portal can show inventory, changes, tickets, backups and billing. An API can make provisioning repeatable. Exportable monitoring can let the customer compare the provider's view with its own. Configuration records can reduce dependence on one technician's memory. None of these features guarantees good operations, but their absence or inaccessibility changes the operating model.
For managed IT, the central question is who owns the system of record for assets and changes. If Ty Cloud maintains customer equipment, the customer should be able to obtain a current inventory, network map, privileged-access list, software version record, backup policy and recent change history in a usable format. For hosting, the customer should understand how servers are provisioned, patched, snapshotted and decommissioned. For connectivity, it should receive circuit references, addressing details, monitoring data and escalation records. For telephony, it should be able to export number inventories, routing rules and user configurations.
The best small-provider model can combine human judgement with disciplined automation. The engineer knows why a customer cannot reboot a particular machine at noon, while the tooling records what was changed and makes the approved state recoverable. The risk arises when personal familiarity substitutes for reproducibility. A customer should test that boundary during procurement by asking Ty Cloud to produce an inventory, restore a sample workload, reconstruct a configuration and hand over the records another competent operator would need.
Recovery is the point where all four layers meet
Ty Cloud's combined proposition becomes clearest in a failure. Imagine a regional customer whose office connectivity, telephone service, hosted application, backup and managed firewall all sit with the provider. The integration is convenient in normal operation. During an incident, recovery may require the legal counterparty to coordinate suppliers, the data centre to remain powered, the ASN and upstream route to work, the backup to be intact, the administrator credentials to be available and a technician to make decisions.
No single public record proves that chain. The company registration proves there is an accountable French entity. The facility claims identify a plausible physical centre. RIPE proves number-resource administration and a live route. The support page proves a contact and remote-assistance method. The service pages prove that Ty Cloud offers recovery testing and off-site backup. Assurance comes from joining those layers in a test.
A useful exercise would begin with a declared failure, such as loss of the production host or primary internet path. The customer and provider would record who detects it, which monitoring alert arrives, how severity is assigned, who can authorise recovery, where the secondary data sits, how credentials are obtained, what network changes are required, when users regain service and whether recovered data meets the agreed point. The exercise should include communication, because a technically successful restore can still fail the business if no one knows which system is authoritative.
The exit test is equally important. Regional trust can make customers postpone it. They should instead ask whether a virtual machine can be exported, whether email and archives can move, whether phone numbers can port, whether configurations and logs can be handed over, and when Ty Cloud and its subprocessors delete residual copies. A provider confident in its service should be able to support an orderly exit. Exit readiness is not disloyalty; it is part of recoverability.
A proportionate buying decision
The public record does not support dismissing Ty Cloud as a name without substance. The company is attributable. Its activity matches the proposition. Arcep records its communications identity, while carefully denying that such a record is approval. RIPE links the same company to LIR status, AS199360 and a live French IPv4 block. The website runs inside that address space. Independent pages identify real services hosted by Ty Cloud. The provider publishes a local number, support hours and a remote-assistance mechanism.
Nor does the record justify treating the whole proposition as assured. The facility's Tier III and environmental claims need independent or customer-witnessed evidence. The visible network surface is small and appeared through one immediate upstream in the captured routing view. The main site did not demonstrate IPv6. The public pages did not establish a second facility, continuous staffed support, detailed service levels, a public incident history or a documented customer automation surface. The team appears small enough that escalation and substitution deserve explicit treatment.
For a modest regional workload, those gaps may be resolvable through direct diligence and a well-written order. The buyer can visit the site, meet the engineers, test a circuit, restore a backup and agree an escalation path. That accessibility is a genuine advantage. For a system with strict availability, regulatory or geographic requirements, the same buyer should require stronger evidence: facility and supplier documents, a service-specific architecture, measured objectives, a secondary location, dual-stack support, route-failover results, round-the-clock duties and an exercised exit.
Ty Cloud's name ultimately does something useful. "Ty" evokes a home in Brittany, and the company has built a public record around proximity: Vannes, a local facility, a local number and a visible network identity. But home is not the same as assurance. Assurance comes from knowing which walls are load-bearing, which utilities enter by separate paths, where the spare key is kept and who will arrive when the lights go out. Ty Cloud offers enough public evidence to make that examination worthwhile.
The purchasing decision should be made from the answers it can demonstrate, service by service, not from the comfort of the name alone.