Summary

  • Tailored Software Services, Inc. can be tied with confidence to Michael Nolan, Lincoln, Nebraska, tssi.com, historical custom-software and database consulting, and a public community-hosting operation that spans the UUCP, mailing-list and self-hosted forum eras.
  • The evidence does not establish the company's present legal status, private customer list, commercial code portfolio, prices, service levels or escrow arrangements. A directory page that says “Closed” is weaker evidence than the live services, but the live services do not prove that private consulting continues.
  • A 2023 migration of roughly two decades of Mailman archives into Discourse shows why continuity is more than retaining source files: identity reconciliation, user habits, inbound email, databases, container configuration, routing and upgrade ownership all became part of the surviving system.
  • The procurement lesson is practical. A customer of a small custom-software supplier should buy and test an exit capability while the relationship is healthy: licensed source, reproducible builds, dependency inventories, restorable data, transferable accounts, operating runbooks, a named successor and a funded transition drill.

A company visible through residue, not a brochure

The most revealing page on tssi.com is not a polished company history. At the time of this research, the root domain returned the standard Apache2 Ubuntu welcome page. The former company page was gone. A MapQuest listing marked Tailored Software Services, Inc. as “Closed,” but also warned that its description had been generated from business information. The directory supplied no closure date, dissolution document or explanation of what “Closed” meant. Meanwhile, huskerlist.tssi.com and nu-sports.tssi.com remained live.

That mismatch is the opening mechanism for understanding small-vendor risk. A buyer would like a clean state diagram: operating, acquired, wound down or dissolved. The public internet more often provides contradictory traces. A storefront vanishes while a daemon keeps accepting mail. A business directory freezes an old telephone number. A domain remains registered. A founder continues to administer one service but no longer markets another. None of those observations, alone, tells a customer whether support will be available on Monday morning.

Tailored Software Services is therefore not a conventional corporate success story or a simple obituary. It is a case in how a supplier becomes legible after its marketing layer fades. The company can be proved. Its historical software work can be proved in broad terms. One long-lived operating surface can be inspected unusually closely. But the commercial details that would matter most to a dependent customer—who owns the code, who can build it, where the credentials are, what happens if the principal becomes unavailable—are absent from the public record.

That absence is not a defect to be filled with guesses. It is part of the finding. Custom software is often private by design. The better it fits a client's internal workflow, the less likely it is to have a public product manual, a visible user community or a searchable release history. When the supplier becomes hard to reach, the customer may discover that its most important application has no external biography at all.

Proving the exact Tailored Software Services

“Tailored software services” is a generic phrase, and TSSI is an acronym used by unrelated businesses. The identity bridge has to be built from stable points rather than name similarity.

The earliest decisive point is a May 1990 Unix-user-group posting. Its signature identifies Mike Nolan, Tailored Software Services, Inc., Lincoln, Nebraska, telephone 402-423-1490, and a UUCP path ending in tssi!nolan. A September 1992 hardware discussion carries the same company name, city and telephone number, now alongside Michael Nolan's [email protected] address. An independently maintained archive of early Linux history preserves a February 1992 item in which Michael Nolan at that address said he had begun uploading Linux information and files to the GEnie UNIX RoundTable.

These records do not prove that Linux distribution was paid company work, and they certainly do not make TSSI a Linux developer. They do something narrower and more useful: they connect the exact corporation, a named operator, Lincoln, the telephone number, the tssi host identity and the tssi.com domain during the early commercial-internet period.

The service bridge comes from TSSI's own historical page. A Common Crawl record of the company page, captured in November 2008, names Michael E. Nolan as president and describes the offering. TSSI said it provided private consulting for hardware and software purchases, the design and implementation of computer software, database management, data conversion and other computer consultation. The same page separately called its web hosting and mailing-list work a community service. That distinction matters: it proves a commercial software-services proposition without pretending that the visible lists were customer projects.

Independent corroboration arrived in 2010. A University of Nebraska–Lincoln Bureau of Business Research report, prepared for the Lincoln Partnership for Economic Development, placed “Tailored Software Svc Inc” and www.tssi.com in “Computer Software Development & Custom Programming Services.” It assigned the company a local-employment band of one to four. That is not a current headcount and should not be converted into one. It is independent evidence that the exact business was understood locally as a very small custom-programming firm.

The bridge reaches the present operating surface through the current forum contract. The HuskerList terms say that users contract with Tailored Software Services, Inc., “the company that runs the forum,” and name [email protected] as the contact. They choose Nebraska law and Lincoln as the forum for specified disputes. The combination of exact company name, same domain, same operator address and same city makes substitution with another “Tailored” business untenable.

One boundary remains. The Nebraska Secretary of State search portal requires an interactive search and reCAPTCHA, and this research did not obtain a downloadable entity record. No claim is therefore made about formation date, good standing, dissolution or current officers. The identity is proved historically and operationally; present legal status is not.

What TSSI actually said it sold

The historical offering was wider than “a programmer writes an application.” It joined purchasing advice, implementation, databases and conversion. Those activities sit on different parts of a customer's dependency map.

Hardware and software purchasing advice influences the base platform: processor architecture, operating system, database engine, peripheral, licence and support channel. Software design and implementation creates the bespoke behavior. Database management keeps the stateful core alive. Data conversion determines whether records can move from an old format to a new one. Consultation connects those layers to the customer's business process.

For continuity purposes, that bundle is more consequential than a standalone code delivery. A custom application can be perfectly readable yet unusable if its database licence expired, its compiler no longer runs, its device interface depends on unavailable hardware, or its conversion rules live only in a consultant's memory. Conversely, a customer may possess no source code but still keep a stable binary running for years because the operating environment never changes. The first arrangement looks safer in a contract folder; the second may appear safer in daily operations. Both can fail abruptly.

TSSI's public materials reveal no named commercial application, customer, programming language, contract form, rate card, warranty or maintenance plan. That prevents a project-level assessment. It also prevents easy sensationalism. There is no basis for saying that a particular TSSI customer was stranded, lost data or suffered an outage.

What can be assessed is the continuity surface implied by the offering. Software design creates source and build artifacts. Database management creates schemas, jobs, permissions, backup routines and recovery knowledge. Data conversion creates mappings and exception rules. Hardware selection creates compatibility constraints. Long-term consultation creates personal knowledge and support expectations. Every one of those assets must be either transferred, reproduced or deliberately retired if the supplier's visible presence disappears.

The 2010 employment band adds a structural observation. A firm with one to four local employees can be responsive because knowledge moves quickly and decisions do not cross departments. The same intimacy can concentrate risk. The report does not tell us how work was divided, so it would be wrong to declare a single-person dependency. But a prudent buyer should treat a small team plus one public technical contact as a signal to test succession, not as proof that succession exists.

The community service that became a continuity record

The community lists are not evidence of TSSI's private customer code. They are more valuable as a public laboratory: a real service whose changing implementation is visible across more than three decades.

In 1990, the address tssi!nolan belonged to the UUCP era, when mail and news moved hop by hop between named systems. By 1992, [email protected] had become a durable internet identity. A 1997 Husker List information post described automated subscription handling, posting rules, a list manager, a web archive and controls intended to keep the subscriber list private. The old company page later said TSSI ran lists for Nebraska sports, Northwestern sports and users of Home Automation Inc. equipment, maintained their archives and hosted a Nebraska chess site.

The domain itself has unusual age. The Verisign RDAP record reports a registration event on August 15, 1991 and, at the research date, an expiration date in 2034. A distant expiration is useful operational hygiene, but not a continuity plan. A domain can be paid for while an application is unsupported; it can also lapse despite healthy code and data. What matters is who controls the registrar account, who can change nameservers, how multifactor recovery works and whether a successor is authorized. None of that is public here.

In 2023, the lists crossed a much more difficult boundary. Mike Nolan described the move from Mailman archives to Discourse in a technical support thread. He said the archive covered about 20 years, that roughly 700 users had been created in the new database, and that about 100,000 posts were coming. Because Mailman did not provide the user IDs the new system needed, he wrote PHP tools to parse Pipermail archives and construct identities.

Those were migration-time estimates, not audited final counts. The current applications show what survived. On July 18, 2026, the HuskerList metadata endpoint reported 57,716 topics, 61,714 posts and 517 users, while the Northwestern sports endpoint reported 51,373 topics, 111,927 posts and 704 users. Both reported activity during the previous 30 days, identified themselves as TSSI discussion lists, listed the same contact email and exposed a current Discourse version string.

The figures should not be added to reconstruct an original archive total. Discourse topics and posts are different measures, imports can split or combine records, users can be inactive or duplicated, and the two communities followed different histories. The important fact is simpler: a large body of conversation remained addressable after a platform change, and the sites were still processing new activity in 2026.

That continuity is impressive. It is not the same as recoverability. A live site proves that the current operator can run it today. It does not prove that another operator can restore it tomorrow.

A migration of identities, not just messages

Moving an archive sounds like copying text. Nolan's account shows why that description is misleading.

Mailing-list messages arrive with headers, dates, sender strings, reply references, encodings and attachments. The same person may appear under several addresses over 20 years. An old address may no longer receive mail. A display name may be missing or inconsistent. A message can quote another message without carrying a machine-readable relationship that the destination platform expects. The source system may treat an email address as enough identity; the destination may require a numeric user ID, account state and unique username.

Nolan's PHP parsers therefore performed more than transport. They converted one identity structure into another. That decision affects attribution, search, moderation, account recovery and privacy. Merge too aggressively and two people become one. Split too aggressively and one person's history fragments across accounts. Activate every historical address and password-reset mail may go to recycled inboxes. Keep everyone inactive and the archive survives but the community does not.

The 2023 community-splitting discussion reveals a second layer. The two sports communities initially shared one Discourse site, separated with groups and categories. Nolan wanted them independently readable and searchable, without forcing members of one community to encounter the other's material. He considered a common Nginx front door, separate subdomains and cloned databases. He also considered whether users from one list should be deleted or merely deactivated in the other.

That is an information-architecture decision with continuity consequences. Deletion reduces unnecessary data but can damage historical attribution. Deactivation preserves records but leaves a larger identity estate to secure and govern. A shared login can simplify access for overlapping members but create a common authentication dependency. Separate databases reduce some forms of cross-community confusion but multiply backup, upgrade and migration tasks.

The discussion records an unusually concrete adoption constraint: three months after the transition, Nolan estimated that only about 5% of users were using the web interface. Most remained email-first. That meant the new system could not be judged by whether its webpage loaded. It had to receive mail, map sender identities, create topics in the right category, distribute messages, preserve threading and avoid loops or duplicates. A technically elegant web-only migration would have failed the actual customer workflow.

This is the heart of operational archaeology. The archaeologist does not merely recover artifacts; the archaeologist infers how people used them. In a business application, the equivalent clues are spreadsheet exports, printer forms, batch windows, manually corrected records, shared inboxes, exception queues and the sequence in which staff click through screens. If a replacement team receives only a repository, it receives the pottery but not the practice.

One container, two communities, several failure domains

By 2025, the public stack had become recognizable as a modern self-hosted application. Nolan's upgrade report described two Discourse communities in a multi-site arrangement, an Nginx layer, container rebuilds, separate site databases and a PostgreSQL extension. An upgrade initially failed because the database user running the migration did not own the vector extension. Changing ownership resolved that step.

The same thread documented a more persistent problem. A rebuild regenerated an Nginx configuration inside the container. Local lines that Nolan had changed were replaced, and hostname traffic could be redirected to the default forum until the modification was reapplied. The thread does not prove a breach, data loss or a measured outage. It does reveal configuration drift: an operational fix existed outside the durable source from which the container was rebuilt.

That distinction is essential. Containers make it easy to replace a running image. They also expose whether configuration has been captured as code. A hand edit inside a disposable container is not part of the system's reproducible state. It works until the next rebuild—the moment designed to erase it.

The official Discourse installation documentation explains the dependency chain behind the apparently simple forum. Supported production self-hosting is Docker-based. The application involves PostgreSQL, Redis, Ruby, Rails and Sidekiq processes, plus Nginx and email configuration. The Discourse Docker repository describes the single-container template as easier, while multiple-container arrangements offer more flexibility, scaling and redundancy at the cost of complexity.

TSSI's public posts support a single-container, multi-site interpretation for the documented period. That is an efficient fit for two modest communities, but it couples maintenance. A rebuild or container-level failure can affect both. The evidence does not tell us whether databases, uploads or mail handling were replicated elsewhere, so no availability judgment can be made. The proper conclusion is a question for any customer: where are the shared failure domains, and has the recovery design been tested at the scope at which failure will occur?

A topology diagram should answer more than “which server.” It should mark the registrar, DNS authority, TLS certificate process, inbound and outbound mail, reverse proxy, application container, database, cache, uploads, object storage, scheduled jobs, monitoring, alert destination, backup store, secrets manager and administrator accounts. It should also mark ownership. A customer cannot transfer an account that belongs personally to a departing developer without the provider's cooperation.

The public TSSI material supplies only part of that map. It is enough to observe the architecture's shape, not enough to certify its resilience.

The customer workflow is part of the system

An application can survive technically and still fail socially. The list migration demonstrates the mechanism.

For an email-first member, the “product” is not a forum database. It is a message appearing in the familiar inbox, with a subject line that threads correctly and a reply action that reaches the group. Web search may be an improvement, but it is not a substitute. A new platform that requires daily browser visits imposes training, password recovery and habit change on users who did not ask for them.

Discourse can support this pattern. Its email workflow documentation describes mailing-list mode, delivery of each new post and replies by email when the instance is configured correctly. But capability is not continuity. The mail exchanger, spam reputation, bounce processing, sender validation, category addresses and per-user settings all have to work together. When one breaks, the website can remain green while the experienced service is down.

The same principle applies to bespoke business software. A warehouse system may depend on a label printer whose exact command language never appeared in requirements. A finance tool may be “integrated” through a person who downloads a CSV every Friday and fixes three rows before upload. A scheduling application may rely on staff interpreting a color that has no formal state code. An overnight job may finish only because someone knows which lock file to delete after a failed run.

These behaviors are often dismissed as workarounds. In continuity planning, they are interfaces. They should be recorded with the same seriousness as APIs.

A useful handover therefore includes workflow evidence: role-by-role task maps, screen recordings using non-sensitive data, sample inputs and expected outputs, exception cases, calendars, batch deadlines, printer and device inventories, external contacts, and a glossary of local terms. It should identify which behavior is intentional, which is accidental and which must disappear during replacement.

TSSI's public service survived because the migration work engaged with identity and email behavior, not merely content. That is an inference from the documented process, not a claim that every choice was ideal. The evidence gives no migration test plan or acceptance report. Still, a community that remains active three years later provides stronger continuity evidence than a screenshot of a completed import.

Source code without a build is a box of parts

Software escrow is the instinctive answer to supplier disappearance: put the source somewhere safe and release it when support ends. That is better than having no source. It is not sufficient.

Current UK government supplier-risk guidance explains the intended protection. A neutral escrow arrangement can give a customer access to source code and proprietary information if a provider goes out of business or stops support. The same guidance says the mitigation should be proportionate to the contract's criticality.

The weakness lies in the noun “source.” A deposit may contain application files but omit the compiler, package registry, private dependency, database migration, image asset, schema generator, licence key, signing certificate or deployment template. It may contain a branch that never produced the running binary. It may be encrypted with a key nobody at the customer holds. It may build only on an operating system image that has vanished.

Modern continuity practice treats a release as a chain of evidence. SLSA build provenance is designed to record where, when and how an artifact was produced so a consumer can verify the build and, where appropriate, reproduce it. The Reproducible Builds documentation shows how easily results vary with timestamps, locales, time zones, filesystem paths, input order, randomness, toolchain versions and system images.

For a new application, the practical requirement is straightforward: a clean, customer-accessible environment must be able to turn the handed-over source into the same releasable artifact, without relying on an employee's laptop. The test should start from documented prerequisites and credentials held by the customer or an escrow verifier. It should produce hashes, logs and a deployable package. It should run automatically often enough to reveal decay.

For a UNIX-era application, exact reproducibility may be impossible. The original compiler may be proprietary, the hardware unavailable and the library licences non-transferable. In that case, the customer needs an honest preservation strategy: capture disk images where lawful, archive install media and manuals, document emulation constraints, export data to open formats, record the running binary's hash, isolate the environment, and plan a replacement before hardware failure turns urgency into ransom.

Public archival can help only in the right circumstances. Software Heritage preserves public source code and supplies durable references to code, directories and releases. It is not a destination for confidential client code without permission, and it does not preserve production secrets or grant missing licences. A private escrow or customer-controlled repository remains necessary for proprietary work.

Nothing public establishes whether any TSSI commercial project had source escrow, a reproducible build or even a surviving repository. That unknown is precisely why a buyer must contract for evidence, not reassurance.

The database is where the business rules hide

TSSI explicitly advertised database management and data conversion. Those services create a second continuity problem: source code may describe what an application intends to do, while the database records what the business has actually become.

Schemas accumulate history. A field named status may contain values that no current code writes but reports still interpret. A customer identifier may be unique only when combined with a branch code. A trigger may update an audit table. A stored procedure may contain pricing logic absent from the application repository. A scheduled job may reconcile records at 2 a.m. A view may be the undocumented interface to a finance tool.

Data conversion adds mappings and exceptions. The easy rows move automatically; the hard rows are resolved by rules such as “treat legacy account type X as Y unless the closure date predates the merger.” If those decisions live in a consultant's script or notebook, the converted database may be correct while the conversion cannot be repeated.

The TSSI list migration offers a benign example. Historical senders had to become destination users. The conversion needed identifiers that Mailman had not maintained in the required form. Nolan built tooling to derive them. The resulting forum database now carries the converted identity decisions. Re-running the migration from raw archives would require the parser, its rules, its inputs and an explanation of how conflicts were handled—not merely the final database backup.

A continuity-grade data package should include the logical schema, physical backup, export in a documented open format, data dictionary, retention rules, integration list, scheduled jobs, migration scripts, checksums, row counts, reconciliation totals, encryption-key procedure and restore instructions. It should define the recovery point and recovery time that the business actually needs. It should also define deletion: a departing supplier should not retain customer data indefinitely because nobody wrote the exit step.

The UK government exit-management template provides a useful benchmark. It calls for current registers of assets, licences, subcontracts, technical infrastructure and operating procedures, plus a complete, uncorrupted transfer of customer data and termination assistance. A small private buyer does not need to copy a government contract wholesale. It does need the same categories of answer.

Backups must be tested, not admired. The official Discourse backup guide notes that a backup can include users, posts, groups, settings and themes, while uploads are optional and plugins must be restored through configuration. It also warns that restore compatibility matters. The existence of that feature says nothing about TSSI's backup practice. The procurement test is a timed restore to a clean environment, followed by application-level checks.

Support continuity is a commercial design decision

Customers often treat support as an operational afterthought and price it as optional insurance. In bespoke software, support is part of the architecture.

The public TSSI evidence shows one named technical operator across decades and a 2010 employment band of one to four. It does not show the private distribution of knowledge. A buyer should neither romanticize nor condemn that scale. A small supplier may know a customer's operation better than a large help desk ever will. The continuity question is whether that knowledge has a path beyond the individual who holds it.

The path has several layers. There should be a second authorized person who can access repositories, infrastructure and accounts. There should be an emergency contact that is not the same inbox as routine support. There should be a customer-held list of third-party renewals and dates. There should be a clear distinction between a defect, a change request and an infrastructure incident. There should be a mechanism for security patches when the original developer is unavailable. There should be a trigger for handover before a long silence becomes a crisis.

Current HuskerList terms are revealing mostly for what they are not. They identify the operator and legal contact, disclaim warranties and limit forum-related liability to $50. They publish no uptime commitment, recovery target or paid support response. That is entirely plausible for a community service. It would be inadequate evidence for a business-critical customer application.

Private consulting may have had separate contracts; the terms say the company may offer other products and services under different terms. None are public. It would therefore be wrong to transfer the forum's liability cap to historical software work. The correct observation is that each operating surface needs its own service contract, and only the forum contract is visible.

Support continuity also depends on upstream communities. A self-hosted open-source platform reduces one form of lock-in because code is available and other specialists can be hired. It introduces another: the operator must follow upstream changes, rebuild containers, migrate databases and keep mail working. Nolan's 2025 upgrade thread shows that access to upstream expertise can resolve a problem. It also shows that the local operator must understand enough of the stack to apply the advice safely.

Open source changes the succession market; it does not eliminate succession work.

Security and compliance after the original developer

The dangerous moment for legacy software is not necessarily when it stops. It is when it continues quietly after its maintenance assumptions have expired.

A stable application can accumulate vulnerable libraries, weak cryptography, over-privileged accounts and obsolete operating systems without changing visible behavior. The business may resist an upgrade because the current version “still works,” while every year reduces the number of people who can repair it. The supplier may be the only party with signing keys or production access. The customer may not even know which components need monitoring.

The NIST Secure Software Development Framework gives buyers and suppliers a common vocabulary for discussing secure development and acquisition. It is not a certificate and does not prove that a particular developer followed it. Its value here is contractual: the customer can ask for protected repositories, reviewed changes, tracked vulnerabilities, release integrity, secure configuration and a response process in terms that are more testable than “industry best practice.”

A 2025 CISA minimum-elements document treats a software bill of materials as a structured record of components and their dependency relationships. For continuity, an SBOM answers “what have we inherited?” It can reveal a library whose update channel is gone or a proprietary component whose licence cannot transfer. It does not supply the source, rebuild the application or tell a replacement maintainer why the component is there.

The public TSSI forum evidence supports bounded observations, not a security verdict. In 2025, an upgrade encountered a database-extension ownership problem and a configuration change that did not persist across container rebuilds. The operator reported fixes and continued seeking a durable answer. Nothing in the record shows exploitation, compromise or data loss. Calling it a security incident would be inaccurate.

It is nevertheless a useful maintenance signal. Database ownership determines who can alter an extension. Container regeneration determines which configuration survives. A hand-edited file can reintroduce wrong routing after an upgrade. These are ordinary operational details with security consequences if unmanaged.

Privacy adds a different inheritance. The historical lists used email addresses as identity. The migration imported long-lived archives and created hundreds of accounts. The current terms require a valid email address and give users account obligations. The public evidence does not disclose a data-protection impact assessment, retention schedule, deletion workflow or jurisdiction-by-jurisdiction compliance analysis. None should be invented.

A replacement operator would need to understand why the data is held, what users were told, which posts are public, how account deletion affects archival attribution, where backups retain removed content, and who can answer rights requests. The legal answer varies by user and jurisdiction. The continuity principle does not: privacy obligations transfer with the data even when the original developer does not.

Finally, security response must survive personnel change. Vulnerability alerts should reach more than one monitored address. Secrets should live in a controlled store, not source files or personal password managers. Domain, cloud and code-host accounts should support organizational ownership. Recovery codes should be sealed and tested. Logs should be retained long enough to investigate but not forever by habit. A successor should be able to patch without first reverse-engineering authority.

Pricing logic: pay for exit before it becomes urgent

No reliable public TSSI rate card, maintenance fee or project contract was found. That prevents a historical pricing analysis, but it sharpens the buyer's pricing question.

Custom software is commonly compared on delivery price: estimate, day rate, milestone or fixed scope. Continuity costs are deferred because they do not add a screen or report. Documentation, escrow verification, a second maintainer, dependency scanning, offsite backups and restore exercises all look like overhead while the principal developer is available.

Their economic value appears when availability changes. A customer that saved a modest sum by declining handover work can face weeks of emergency discovery at premium rates. The replacement team must identify the running version, obtain access, reconstruct a build, interpret data and stabilize production before it can make the requested change. The buyer pays twice: once for archaeology and again for development.

The right pricing unit is therefore not simply “an escrow deposit.” It is a tested exit capability. A practical contract can price an initial continuity package, small updates at each release, an annual restore-and-build drill, and a transition rate agreed in advance. The scope should shrink for a low-criticality tool and expand for a system that controls money, safety, regulated data or daily operations.

Escrow verification is worth paying for because a stale deposit creates false confidence. Verification can check that the deposit is complete, builds in a documented environment and matches a released artifact. The customer should also price the right to use the material after a release trigger. Possession without an adequate licence is not continuity.

Financial monitoring should be proportionate. A four-person supplier should not be burdened with enterprise reporting designed for a multinational. But a customer can ask simple questions annually: Has ownership changed? Is the key-person coverage plan current? Are insurance and critical subcontractors unchanged? Can the company still access every account? Has the exit package been updated? Did the test pass?

These questions are cheaper before distress. Once the supplier stops responding, negotiation leverage and available knowledge decline together.

Competition is less important than replaceability

The 2010 Lincoln report placed TSSI among many local software-development and custom-programming firms, several in the same one-to-four employment band. That suggests customers had alternatives at the category level. It does not mean another firm could take over a TSSI system without preparation.

Custom software competition has two stages. Before award, suppliers compete on trust, domain knowledge, technical approach, responsiveness and price. After years of customization, the incumbent's advantage comes from accumulated context. A competitor may be better at modern engineering and still need months to understand why the application behaves as it does.

Switching cost therefore grows in hidden increments: each undocumented exception, personally owned account, unpinned dependency, direct database edit and one-off integration. The customer may experience excellent service throughout. Lock-in is not necessarily abusive conduct; it can be the natural residue of successful collaboration.

Replaceability is the counterweight. It does not require changing suppliers regularly. It requires maintaining the credible option to do so. The option disciplines both sides: the customer can plan rather than panic, and the supplier can hand over without an improvised, adversarial exit.

An open-source platform such as Discourse creates a broad replacement labor pool relative to a proprietary in-house framework. TSSI's forums still contain local complexity—migration rules, email behavior, multi-site routing and community policy—but the underlying application has public code and documentation. A private custom application may have no such market. The contract must manufacture replaceability through artifacts, rights and tests.

A procurement test for a small custom-software supplier

The lesson from TSSI is not “avoid small vendors.” It is “buy continuity in a form another competent person can exercise.” The following test is designed for a small or medium-sized customer commissioning bespoke software from a compact supplier.

Prove identity and authority

Verify the exact legal entity, trading names, registered address and people authorized to bind it. Record the domains, code-host organizations and cloud accounts it controls. If a founder's personal account is used during development, require migration to organizational ownership before production. Name both routine and emergency contacts.

TSSI's public history shows why exact identity matters: a generic name and acronym could easily lead to an unrelated company. The stable combination of exact corporate name, Nolan, Lincoln, telephone and domain makes the bridge. A procurement file should not require future researchers to reconstruct that chain from Usenet.

Classify the operating criticality

Describe the business process the software controls, maximum tolerable downtime, acceptable data loss and regulatory constraints. Identify peak periods and manual fallbacks. A sports discussion list and a payment engine do not need the same continuity spend. NIST's contingency-planning guidance emphasizes coordinated plans, procedures and technical measures, including alternate equipment, processing and locations. The customer's impact assessment should determine which are necessary.

Establish ownership and licences

State who owns newly written source, documentation, schemas, designs and test data. List every third-party component and the customer's right to use, transfer or replace it. Define rights after termination, insolvency, death or incapacity of a key person, material breach and prolonged failure to support. Do not assume that paying an invoice transfers copyright or a licence broad enough for a successor.

Deliver source continuously

Put the repository in an organization the customer can access, or mirror it automatically to customer-controlled storage. Include branches, tags, history, issue references, database migrations, infrastructure definitions and release notes. Require each production release to map to an immutable commit and artifact hash. If confidentiality requires escrow, update the deposit at every material release rather than annually by memory.

Rebuild from clean ground

Give a technically competent person who did not develop the application a clean machine or isolated environment. Ask that person to build, test and package the release using only the handover materials. Record missing tools, credentials and undocumented steps. Repeat after major dependency or platform changes. A passing demonstration is more valuable than a hundred-page document never used.

Inventory the supply chain

Produce an SBOM and a human explanation of critical dependencies. Identify package sources, private registries, operating images, compilers, database versions, device drivers, fonts, certificates, signing keys and paid licences. Record end-of-support dates and alternatives. An inventory should answer both a vulnerability question and a succession question: can another party lawfully and practically obtain every component?

Make data independently recoverable

Supply native backups and documented open-format exports. Include schemas, dictionaries, retention rules, encryption procedures, job schedules and reconciliation checks. Restore into an empty environment and compare totals and critical workflows. Make sure attachments and object storage are included; database-only recovery may produce a site full of broken links.

The TSSI forum example is concrete: official Discourse documentation says plugins live outside the database backup in app.yml, while uploads may or may not be included. A successful SQL restore without those elements would be incomplete.

Document the human interfaces

Record user roles, actual workflows, exceptions, batch deadlines, email patterns, devices and manual controls. Interview the people who perform the work, not only managers. Preserve representative inputs and expected outputs with sensitive data removed. The TSSI migration's low early web adoption shows how easily a platform project can miss the interface users value most.

Separate secrets from knowledge

Store secrets in a controlled system with role-based access, recovery codes and audited succession. Document what each secret unlocks without placing the secret in the runbook. Ensure at least two authorized people can recover the registrar, infrastructure, email, repository, certificate and backup accounts. Revoke access through a checklist when personnel change.

Preserve configuration as a build input

Treat proxy rules, database extensions, scheduled jobs, firewall settings, certificate automation and mail configuration as versioned artifacts. Ban unexplained production-only edits. After every rebuild, run automated hostname, email, login, upload and background-job checks. TSSI's public upgrade thread is a precise illustration: a fix inside a regenerated container did not become durable merely because it worked once.

Define support and transition service levels

Specify response and restoration targets, supported versions, maintenance windows, vulnerability handling and after-hours coverage. Define how priority is decided and what evidence closes an incident. Pre-agree transition assistance, rates and duration. Require the supplier to cooperate with a named replacement and to provide a current asset and account register.

Test the successor

Choose a second maintainer before the primary supplier disappears. The successor need not work on every release. An annual supervised exercise—build, restore, diagnose one seeded fault and deploy to staging—reveals whether the handover is real. Rotate the participant occasionally so continuity does not simply move from one indispensable person to another.

Record evidence, not adjectives

Replace “fully documented” with a document index and last-tested date. Replace “backed up” with a restore log, checksum and storage separation. Replace “secure” with controls, scan results, patch status and incident contacts. Replace “portable” with a successful deployment outside the supplier's environment. Procurement should reward demonstrable exit readiness, not punish honest disclosure of limitations.

A rescue sequence for customers already dependent on legacy code

Many buyers will encounter these questions after the relationship has gone quiet. The sequence then matters. Trying to modernize before stabilizing evidence can destroy the very clues needed for recovery.

First, preserve the running system. Capture versions, hashes, screenshots, configuration, logs, scheduled jobs, service accounts, certificates, database backups and infrastructure metadata. Do not reboot obsolete hardware casually. Do not expose an unpatched image to a new network merely to inspect it. Use qualified forensic or legacy-system help where safety or regulated data is involved.

Second, establish legal rights. Find contracts, invoices, licences, statements of work, change requests and correspondence. Determine who owns source and data, whether third-party licences transfer, and whether reverse engineering or archival copying is permitted. Technical access without legal authority can turn a continuity problem into a dispute.

Third, secure administrative control. Move registrar, cloud, repository, email and monitoring accounts into customer-controlled organizational ownership where the contracts allow it. Add a second authorized administrator. Rotate credentials with care: changing a password can break an unattended integration whose dependency has not yet been mapped.

Fourth, take multiple data exports. Preserve a native backup for fidelity and an open export for escape. Verify checksums. Restore a copy without touching production. Compare record counts, financial totals, attachments and representative workflows. Note every manual repair needed; each is a missing runbook step.

Fifth, reconstruct the build. Start with the production artifact and work backward to the commit, toolchain and dependencies. If the source cannot reproduce the artifact, do not immediately discard either. The difference may reveal a production-only patch, missing generated file or wrong branch. Record uncertainty explicitly.

Sixth, map integrations and people. Trace inbound and outbound files, mailboxes, APIs, devices, reports and human approvals. Ask users what they do when the system “gets stuck.” Their answers often identify hidden state transitions faster than static code review.

Seventh, choose among containment, re-platforming and replacement. Containment isolates and documents a stable legacy system while reducing change. Re-platforming moves it to a supportable environment with minimal functional alteration. Replacement redesigns the workflow. The right choice depends on criticality, code quality, legal rights, data portability and remaining domain knowledge—not fashion.

Eighth, run the exit. A plan that has never transferred responsibility is still a hypothesis. Put the successor on call for a controlled period, perform a release without the original maintainer leading, restore from the customer-held backup and close the gaps discovered.

The order is deliberately conservative. Archaeology begins by protecting context. Modernization begins only after the evidence can survive the dig.

What can and cannot be concluded about TSSI

The public record supports a more interesting conclusion than either “the company closed” or “the company is still operating normally.”

Tailored Software Services, Inc. was a real Lincoln company associated consistently with Michael Nolan and tssi.com. It advertised software design and implementation, database management, data conversion and technology consulting. An independent 2010 report categorized it as a small custom-programming business. Its domain has existed since the early 1990s. Its community services moved from mailing-list infrastructure to a modern forum stack, and two sites remained active in July 2026.

The visible commercial shopfront has receded. The historical services page is no longer at the root, which now presents a default server page. A generated directory marks the business closed. Those facts justify describing the commercial presence as faded or uncertain. They do not establish legal dissolution or the end of every service.

The current forums show operation, not necessarily commercial software consulting. Their terms name the corporation, but the historical homepage called the lists community service. No public evidence identifies a private customer, application, contract, price, support incident or abandoned codebase. The article therefore does not claim that any customer was harmed when the marketing site disappeared.

No public evidence establishes source escrow, build reproducibility, backup frequency, successful restore drills, redundancy, compliance certification or security testing for TSSI's private work or forums. The current Discourse version string is a maintenance signal, not an audit. The 2025 upgrade thread is evidence of hands-on administration and configuration friction, not a breach report.

That combination is enough for a continuity analysis because the uncertainty is authentic. A customer evaluating a small supplier rarely receives perfect public evidence. The job is to convert unknowns into contract deliverables and tested controls before dependency deepens.

Watchpoints on the surviving public surface

The two forums provide observable signals for future monitoring without intruding into private systems.

The first is domain and account continuity. A long registration horizon is positive, but changes in nameservers, certificate failures or loss of the operator contact would warrant investigation. Those signals should never be treated as proof of corporate status on their own.

The second is application maintenance. The live metadata currently reports a recent Discourse version and continuing posts. Extended version stagnation, failed email delivery or simultaneous unavailability across both communities would be more meaningful than the root homepage because the forums are the documented operating services.

The third is configuration durability. The 2025 thread exposed a rebuild-sensitive Nginx change and a database-extension ownership issue. A future clean rebuild without hostname confusion would be stronger evidence than a manual repair. Public evidence may never show whether that test occurred, so outside observers should keep the distinction between “running” and “reproducible.”

The fourth is succession. [email protected] remains the public contact across the historical and current record. A second organizational contact, updated terms or a documented stewardship transfer would reduce visible key-person concentration. Its absence does not prove there is no private succession plan; it keeps the public answer unknown.

The fifth is archive integrity. Topic and post counts will change with activity, moderation and software behavior. Sudden large reductions would merit explanation, but raw count differences are not automatically data loss. Better signals would include published migration notes, backup policy or an independent archive handover.

These watchpoints are not a scorecard. They are examples of evidence that can distinguish continuity from mere uptime.

The difference between survival and recoverability

Tailored Software Services presents a rare long view. A UUCP signature from 1990, a domain registered in 1991, mailing-list instructions from the 1990s, a tiny custom-programming company in a 2010 industry report, a 2023 archive migration and active 2026 forums all belong to the same identity chain. The public service changed almost every technical layer while retaining its communities.

That is survival.

Recoverability asks a different question: could an authorized successor reproduce the service, with its data, behavior and obligations, without depending on the person who has carried it this far? The public record cannot answer. A live database, an old source tree and a paid-up domain are each valuable, but none is the whole system.

For customers of bespoke software, the lesson is not to wait for a default homepage or a “Closed” label. By then, the cheapest continuity window may have passed. Ask for the build while the developer can explain it. Restore the backup while production can be compared with the result. Transfer the accounts while both parties can approve the change. Record the exceptions while users still remember why they exist. Fund the successor before succession is urgent.

Custom software becomes operational archaeology when the chain between artifact and practice breaks. The best continuity plan does not eliminate archaeology; every long-lived system accumulates history. It makes the excavation bounded, lawful and repeatable—and ensures that the next maintainer begins with a map rather than a ruin.