The Approval Loop Is the Product at FAIRHAVEN SOFTWARE PRODUCTS INC.

Summary

• Public evidence supports an operating bridge from Fairhaven’s historical Massachusetts presentation to today’s Fairsoft business in Kanata, but it does not establish a legal transfer of old contracts, intellectual property, trademarks or liabilities to the active Canadian corporation. A buyer must identify the contracting company in the signed documents rather than infer it from the brand.
• Fairsoft’s iterative “Spiral Development” approach can reduce requirements error because users see and test the system while it is built. It can also turn informal reactions into disputed acceptance unless each demonstration records the data, workflow, exceptions, security conditions and definition of done.
• FileMaker can make a bespoke operational system relatively fast to build and change, while its files, scripts, layouts, integrations, licensing and administrator credentials can create layered dependence on Claris, the developer and the host. Data export alone is not an exit plan.
• The public footprint describes a very small team, hosting, conversion and long-running support, but publishes no service levels, recovery objectives, current price card, security assurance pack, subprocessor list or succession plan. Those are procurement questions, not reasons to presume either strength or weakness.
• A defensible purchase ties payment to tested outcomes, gives the customer full administrative and data access, rehearses restoration and export, separates platform and service charges, names substitute support arrangements, and makes termination assistance part of the original bargain.

The moment a demonstration becomes a liability boundary

Imagine a small distributor replacing the spreadsheet that quietly runs its business. The sheet contains customer names, stock adjustments, special prices, half-documented exceptions and the unwritten knowledge of the employee who fixes every mistake. A developer shows the first working version of a replacement: an order screen, a production queue and a shipping report. The customer says it looks right. Two weeks later, the same customer discovers that split shipments, tax exemptions and returned deposits behave differently at month-end. Was the screen approved, the workflow approved, or the business rule approved?

That question is the centre of Fairsoft’s proposition. A historical Fairhaven page describes all development projects as fixed-priced and says customers inspect and interact with work in progress. The current Fairsoft services page preserves the essential loop in plainer language: the company builds a little, users try it, and the process repeats. Its current company page says Fairhaven will not accept a project unless the customer participates in reviewing appearance, data flow and reports, while decisions and approvals remain with the customer.

This is sensible product discovery. Users often cannot describe an operational exception until a working screen forces a choice. Frequent demonstrations surface disagreement earlier than a grand reveal. They create familiarity that can reduce training. They allow a small supplier and a small buyer to make progress without producing a book-length specification before either side understands the work.

But iteration does not make scope risk disappear. It converts scope risk into a sequence of decisions. Under a fixed fee, every decision also allocates money and time. If “approved” merely means that a manager liked the screen, the developer may later treat it as acceptance of underlying behaviour. If approval has no recorded test data, expected result or named authority, the buyer may believe it has preserved flexibility when it has actually consumed the allowance for change. Conversely, if every new insight is treated as included work, the supplier carries an open-ended obligation inside a capped price.

Fairsoft calls its method “Spiral Development,” but buyers should not assume that this label imports every property of Barry Boehm’s risk-driven spiral framework. Fairsoft’s public description establishes iterative customer review; it does not publish a complete engineering handbook, risk register, test standard or contractual acceptance procedure. The distinction matters. A methodology is what the parties actually do and document, not what a familiar name might imply.

The control problem, then, is not whether iteration is good. It is whether each loop has an explicit purpose. One loop might validate whether a user can enter an order. Another should validate migration accuracy. Another should test access rights. Another should prove that a backup can be restored. A sound contract distinguishes exploratory feedback from formal acceptance, records open defects, names who can approve, and prevents silence or routine use from becoming accidental sign-off. The most important deliverable is the evidence that both parties mean the same thing when they say “done.”

Four public identities, one operating story and one unresolved legal step

The name requires more diligence than a normal supplier check because several true statements can be mistaken for one complete legal story.

First, the Fairsoft page carrying a 2011 copyright notice identifies “Fairhaven Software Products, Inc.” at 3 Long Road in Fairhaven, Massachusetts. It contains the fixed-price statement and the older explanation of the iterative process. The historical product pages also present the company as the publisher of Nutshell and Ultra-Plus database products. A trademark archive associates a FAIRSOFT US filing, serial number 78530966, with a company of that same name. These records support a real Massachusetts-era presentation; they do not, by themselves, show who owns the mark or customer obligations now.

Second, the live site continues the same operating story. It uses the Fairsoft name, the fairsoft.com domain and the 800-582-4747 number visible on the historical page. It names Tom as founder, says Sue has worked with Fairhaven since 2000 and Asa with Fairsoft since 2009, and presents a business history running from Nutshell distribution in the 1980s through FileMaker development and hosting from 1999 onward. That is strong evidence of brand, personnel and service continuity. It is still company-supplied evidence, and continuity of trading presentation is not the same as legal succession.

Third, Canada’s official federal register lists Fairhaven Software Products, Inc., corporation 1020680-6 as an active corporation governed by the Canada Business Corporations Act since April 25, 2017. At the evidence freeze, the register showed a current Ottawa registered office, Susan Carter as director and the sole disclosed individual with significant control, and annual filings through 2026. The Canadian BBB listing connects the April 2017 incorporation, Sue Carter, the Fairsoft website, the same toll-free number and a previous Kanata address. BBB says its information is intended for buyer judgment and is not a guarantee, so it is corroboration rather than corporate authority.

Fourth, the Claris partner listing expressly calls the company “Fairhaven Software Products, Inc. (Fairsoft),” locates its headquarters in Kanata, describes database design, conversion, training, hosting and consulting, and reports a staff of three. This is the cleanest public bridge between the legal-style name, the Fairsoft brand, the current Canadian location and the FileMaker business. Claris also labels the partner Platinum and lists reseller and solution activities.

Together, these records are sufficient to analyse the active Canadian company as the current public operating centre of Fairsoft. They are not sufficient to say that the Canadian corporation purchased the Massachusetts corporation, received its trademark, assumed its warranties, obtained every customer file, or became liable for every historical contract. No public asset purchase agreement, merger record, assignment, licence, novation notice or customer terms page was found in the frozen evidence set.

The correct answer to “which Fairhaven entity owns the current customer obligation?” is therefore contractual, not inferential. For a new engagement, the obligation belongs to the company named in the executed master agreement, statement of work, hosting schedule and invoice. If the intended counterparty is the Canadian corporation, the documents should say “Fairhaven Software Products, Inc.,” include corporation number 1020680-6, identify the notice address and governing law, and match the payee and tax details. A legacy Massachusetts customer should ask for the original agreement plus any assignment or novation.

A brand name, shared telephone number or partner badge cannot perform that legal work.

This is especially important because Claris tells customers that they contract directly with the independent member company, not with Claris, and that Claris is not liable for a partner’s acts or omissions. The partner listing validates an ecosystem connection; it does not guarantee performance or identify which same-named corporation signed a particular bargain.

What Fairsoft appears to sell now

Fairsoft’s public offer is a mixture of bespoke development, legacy conversion, hosting and operational support, all centred on FileMaker. The company’s history page says it distributed the DOS database Nutshell from 1983 to 1989, published Nutshell and successor products from 1989 to 1999, and has used FileMaker for database development, vertical solutions and hosting since 1999. The home page presents examples spanning awards manufacturing, field service, product compliance tracking and machinery location. The services page lists design, development, hosting, conversion, consulting and remote support.

This is not a conventional subscription product with one standard workflow. The value proposition is that Fairsoft learns how a customer actually works and shapes a system around that reality. Its named examples describe order entry, production, shipping, accounts receivable and payable, barcode scanning, card processing, field dispatch, QuickBooks communication and regulatory product tracking. Such breadth suggests that the supplier’s most valuable asset is accumulated pattern recognition: knowing which questions expose a broken handoff and which automation will merely accelerate a bad process.

The public examples should be read as illustrations, not a current reference list. Several mention FileMaker 11 or 12, versions that make the copy visibly old. The site says it has served more than 10,000 customers, and the Claris listing repeats a “10k+” figure, but neither source defines whether that means historical product licences, consulting engagements, active hosted systems or current support relationships. A buyer should not turn a cumulative company claim into an assumption about present scale.

The legacy business is nevertheless relevant to the current thesis. Fairsoft has spent decades on both sides of software dependence. It once published database programs; it now offers to move users from those aging programs into FileMaker. Its Nutshell and Ultra-Plus page warns that newer Windows versions do not support the older products and describes a conversion utility that carries fields, layouts and records forward while leaving macros and links to be recreated at additional cost. That is an unusually clear demonstration of the difference between preserving data and preserving a working institution.

For a customer, the purchase is not simply a database. It is a designed operating environment plus a continuing service relationship. The environment may include desktop clients, iPhones or iPads, browser access, hosted files, integrations, reports, email, PDFs, barcode devices and accounting connections. The relationship may include discovery, iterative changes, platform licences, hosting, backups, remote support and later upgrades. Each element has its own owner, recurring cost and exit condition. Procurement fails when all of them are compressed into one reassuring phrase such as “custom solution.”

How a Fairsoft system can become the operating surface

FileMaker sits between a spreadsheet and a fully bespoke application stack. It lets a developer combine data tables, relationships, screens, calculations, scripts, reports and access controls in one environment, then deliver the result through FileMaker Pro, FileMaker Go, a browser or integrations. Claris describes FileMaker Server as the host for databases used by Pro, Go, WebDirect, web publishing and the Data API. That breadth is why a small team can replace several disconnected tools without separately building every interface and service.

The speed is real, but so is concentration. A Fairsoft application can become the place where an order changes status, a price is authorized, a field technician receives work, a barcode becomes inventory, a report becomes an invoice and a manager decides what happened. Once those actions depend on scripts and layouts, the system is no longer a passive record. It is the operating surface of the business.

That surface has at least six layers a buyer should map.

The first is the human workflow: roles, queues, approvals, handoffs and exceptions. A field called “complete” may mean packed to one team, invoiced to another and paid to a third. The second is stored information: customer, product, transaction, attachment, audit and configuration data. The third is behaviour: calculations, scripts, validation, scheduled jobs and report logic. The fourth is access: individual accounts, groups, privileges and administrator rights. The fifth is connection: QuickBooks, email, payment, mapping, barcode, web and external data services.

The sixth is operation: hosting, certificates, monitoring, patching, backup, restoration and support.

An iterative demonstration usually shows the first three layers because they are visible. The last three can remain invisible until failure. A report can look correct while the scheduled job that produces it lacks monitoring. A mobile screen can work while an integration secret belongs to the developer. A hosted file can be encrypted while the customer lacks the encryption password. A daily backup can exist while nobody has proved it restores. The demonstration loop should therefore include operational and exit evidence, not just interface approval.

FileMaker provides several technical paths for connection. ODBC and JDBC sharing can expose a file as a data source, subject to explicit privileges. The Data API can let other services read and change records through authenticated web requests. FileMaker can also export common formats. These capabilities reduce isolation, but only if the design enables them, the customer has credentials, field meanings are documented and integrations can be rebuilt without undocumented knowledge.

The key procurement artefact is therefore a current system map. It should name every file, table family, major script, scheduled task, plug-in, external service, certificate, service account, data flow and responsible party. It should show which elements are owned by the customer, Fairsoft, Claris or another provider. Without that map, “FileMaker solution” is a label covering an unknown dependency graph.

Conversion is where old dependence can be copied into new software

Fairsoft’s history gives it a credible conversion story. The Claris listing says the company is especially adept at moving information between platforms, particularly from Nutshell and Ultra databases to FileMaker. Fairsoft’s own conversion page provides more useful detail: its utility carries fields, layouts and records, while macros and links must be recreated separately.

That distinction should govern any migration, not only a Nutshell conversion. Fields and records are the visible payload. Macros and links represent behaviour and context. A customer can receive every row and still lose the rules that made the rows meaningful: how a status changes, which duplicate wins, when a price is overridden, where an attachment lives, why a report excludes a transaction, or what an identifier connects to outside the system.

The first conversion deliverable should be an inventory of the source. Count tables or files, records, fields, attachments, users, reports, automations, integrations and known defects. Identify character encodings, date conventions, duplicate keys, orphan records and values with overloaded meanings. Freeze a reconciliation pack before transformation: record counts, control totals, sample histories and exception lists. If the old system calculates financial or compliance outputs, preserve a representative set of expected results.

The second deliverable should classify each source element. Some information transfers directly. Some requires mapping. Some should be cleaned. Some behaviour must be rebuilt. Some obsolete behaviour should be deliberately retired. The customer, not just the developer, should approve those choices because a technically successful conversion can still erase a business rule.

The third deliverable is repeatability. A conversion should be runnable more than once. Early rehearsals expose missing fields and performance limits; the final run should not depend on an improvised sequence known to one person. The project should record the conversion version, input hash, output counts, exceptions and sign-off. For a live cutover, it should define the last permitted change in the old system, the reconciliation window, the rollback trigger and who makes the go-live decision.

The final deliverable is an untouched source archive plus a readable export. Fairsoft’s own history shows why. A proprietary DOS product can become difficult to run even when its data still matters. A FileMaker file is much more capable, but the buyer should assume that today’s supported platform will also change. Preservation requires both the working application and a platform-neutral representation of essential information and documentation.

Conversion skill is a reason to consider Fairsoft. It is not a reason to relax conversion acceptance. The more experience a supplier has, the more concrete its reconciliation plan should be.

Fixed price does not fix the thing being bought

The historical Fairsoft page makes a striking claim: all development projects are fixed-priced. The current site still describes the iterative process but does not repeat that universal pricing statement. A buyer in 2026 should therefore treat fixed pricing as a historical claim until a current proposal confirms it. No public price card for Fairsoft development, hosting or support was found.

If a fixed fee is offered, the important question is what has been fixed. It could be price for a fixed list of functions. It could be price for a fixed number of iterations with variable scope. It could cover a discovery phase whose output is a later quote. It could exclude conversion exceptions, third-party work, travel, licences, hosting, data cleanup, training or post-launch support. Each structure allocates uncertainty differently.

The UK government’s guidance on contracting for agile delivery warns that highly uncertain work is less likely to achieve its outcome under a rigid whole-project price and suggests fixed-price phases as one way to contain commercial risk. That does not prove any Fairsoft project will fail or succeed. It explains why the approval loop needs commercial rules.

A workable iterative fixed-fee agreement needs a hierarchy of evidence. The signed statement of work should define the outcome, essential workflows, excluded work, environments, data assumptions, integrations and non-functional requirements. A prioritized work list should describe features in testable language. Each demonstration should produce decisions and open questions. Formal acceptance should occur against agreed tests, not general satisfaction. A change process should show how a new request displaces lower-priority work, changes price or moves the date.

Defects should be distinguished from enhancements by reference to expected behaviour.

Customer participation also has a cost. Fairsoft emphasizes that decisions remain with the customer. The agreement should identify a product owner with time and authority, subject specialists who can explain exceptions, and a security or technical contact who can approve access and deployment. It should state what happens when the customer cannot decide: does work pause, does the supplier proceed on an assumption, or does the delivery date move? An approval deadline without a documented assumption process is a trap for both sides.

Payment should follow evidence. A deposit may fund discovery. Later milestones can correspond to a reconciled conversion rehearsal, acceptance of a workflow group, a security review, production readiness and a completed exit pack. Holding a portion until documentation, administrator access, restoration evidence and final export are delivered gives operational work the same status as visible features.

The supplier needs protection too. If every customer insight is free, a fixed fee becomes unsustainable and quality becomes the pressure valve. A fair arrangement allows reprioritization inside a fixed envelope and requires explicit change for genuinely additional outcomes. Transparency is more valuable than the fiction that uncertainty has vanished.

Hosting turns a development supplier into an operational dependency

Fairsoft says it hosts FileMaker databases on encrypted servers, performs daily backups and can provide a requested copy. Its services page also says hosting includes multiple rotating backups and the ability to download a copy at any time. These are useful commitments in marketing language, but they are not a service description. They do not state where the servers are, which FileMaker version is running, how often backups occur, how long they are retained, whether copies leave the primary environment, who holds encryption credentials, how restoration is tested, or how quickly service returns after failure.

Claris now distinguishes three hosting choices: managed FileMaker Cloud, customer-managed FileMaker Server and third-party hosting. Its hosting comparison says third-party offerings vary, while self-hosting places infrastructure and maintenance responsibility on the customer and FileMaker Cloud automates more of it. A buyer considering Fairsoft hosting should ask which of these it will actually receive. “Cloud” is not a sufficient answer.

The 2026 platform adds useful resilience options. FileMaker Server 2026 release notes describe remote backup and a standby server capable of taking over from a primary. Claris describes these as add-ons, not proof that every third-party host uses them. The same release notes show why version evidence matters: FileMaker Server 2024 version 21.1.8 fixed a path traversal flaw that could permit remote code execution through a system script schedule. This is a Claris product issue, not evidence of a Fairsoft incident. It does show that “encrypted” and “backed up” do not substitute for timely patching.

A hosting schedule should define measurable recovery objectives. Recovery point objective states how much recent work may be lost. Recovery time objective states how long restoration may take. The document should name the backup frequency, retention, location separation, encryption, monitoring, restore-test frequency and evidence available to the customer. Claris documents automatic, scheduled, progressive and remote backup types; the contract should say which are enabled, not merely cite platform capability.

The buyer should witness a restoration before go-live and at least annually. Select a backup, restore it into an isolated environment, verify that files open, attachments are present, integrations are disabled or safely redirected, key reports reconcile, accounts work and the elapsed time meets the promise. A backup log proves that a copy job ran. A restore exercise proves that the business can resume.

Ownership must also be operational. The customer should have a current offline copy of every FileMaker file and externally stored container, the encryption password in its own controlled vault, platform licence records, certificate inventory, administrator access and a documented path to another host. If Fairsoft manages DNS, certificates or integrations, the customer should still control the accounts or have an escrowed recovery route.

Finally, the agreement needs a failure communication plan. It should define support hours, severity levels, acknowledgment and update intervals, emergency contacts, maintenance notice, incident notice and escalation. The site publishes a telephone number, but a phone number is not a service level.

Security capability is not deployment evidence

Fairsoft’s site refers to AES encryption and secure encrypted servers. FileMaker can support strong controls. Claris documents database encryption, SSL for information in transit, individual accounts, privilege sets, external authentication, logging and secure hosting folders. FileMaker Cloud has SOC 2 Type 2 coverage and ISO/IEC 27001 and 27018 certifications according to Claris. None of these facts establishes how a particular Fairsoft-hosted application is configured.

Security diligence should begin with the deployment boundary. Is the file in FileMaker Cloud, on Fairsoft-managed FileMaker Server, at another host or on customer infrastructure? Who patches the operating system, FileMaker Server, web server and plug-ins? Who imports and renews the certificate? Who can access backups? Where are logs retained? Which countries can support personnel access information from? Are production and test information separated?

Identity is the next test. Claris recommends an individual account for each person, and its account guidance explains that privileges apply within each file. A multi-file application can therefore hide inconsistent access rules. The customer should receive a role matrix covering every file and interface, prove that former employees are removed promptly, require multi-factor authentication where the chosen hosting route supports it, and prohibit shared administrator use except through a controlled emergency procedure.

Administrative access is also an exit right. Claris states that full access is required to manage a file completely. The customer should hold at least one tested full-access route that is not dependent on a supplier employee. Encryption credentials should be separate and customer-controlled. Service accounts should belong to the customer’s identity estate where practical. A supplier can perform daily administration without being the only party able to open, change or migrate the application.

Logging must match the risk. FileMaker Server monitoring documentation describes event, API, administrator, client, performance and schedule logs. The contract should say which are enabled, how long they are kept, who reviews alerts and what the customer can obtain after an incident. Sensitive applications may need information-level audit fields as well as server logs, because server telemetry does not necessarily explain who changed a business record and why.

Secure development evidence should be proportionate to a small supplier. A buyer need not demand a giant-company ceremony. It can ask for a component inventory, supported-version list, vulnerability intake process, patch targets, code review practice, test evidence, separation of test and production credentials, and disclosure of plug-ins and external libraries. CISA’s software acquisition guidance is designed to help purchasers focus questions on their actual context, while its detailed acquisition guide asks suppliers about component provenance and software bills of materials.

No credible public report of a Fairsoft-specific breach, outage or enforcement action was located in the frozen evidence set. That is an evidence gap, not a clean security bill. Small private suppliers often have little public incident history in either direction. The correct response is to ask for incident history under confidentiality, current controls, cyber insurance, notification terms and a tabletop exercise—not to convert silence into a claim.

Privacy responsibility follows the information, not the hosting label

Fairsoft markets to organizations in the United States and Canada and describes systems that can contain orders, payments, field work and regulatory tracking. Those uses may involve customer, employee or other personal information. The buyer remains responsible for understanding what is collected, why it is needed, where it moves, how long it is retained and who can access it.

The Office of the Privacy Commissioner of Canada says in its outsourcing guidance that an organization subject to PIPEDA must take reasonable steps to protect personal information handled by a third-party processor and satisfy itself that the provider has suitable policies, training and safeguards. Processing abroad is not prohibited, but foreign law still applies. The Office’s accountability guidance emphasizes comparable protection through contractual or other means and limits on the processor’s use.

A Fairsoft hosting or support agreement should therefore include a data-processing schedule. It should define the parties’ roles, permitted purposes, categories of information, locations, subprocessors, staff access, confidentiality, security measures, retention, return, deletion, audit evidence and help with individual rights. It should require prior notice of material subprocessor or location changes. Remote support should use named accounts, customer approval where appropriate, logging and automatic expiry.

Incident terms must allow the buyer to meet its own deadline. Canada’s privacy regulator says organizations subject to PIPEDA must report breaches posing a real risk of significant harm, notify affected people and keep records of all breaches. A supplier contract should require notice quickly enough for assessment, preserve evidence, support investigation and clarify who communicates externally. “Without undue delay” is stronger when paired with a maximum initial notification period and required content.

Data minimization is a design question, not a legal appendix. The iterative process should ask whether each field is necessary, whether old information should migrate, whether test systems need real personal information and whether reports expose more than a role requires. Approval of a screen should include approval of the information it reveals.

A three-person listing changes the continuity calculation

Claris’s Fairhaven listing reports three staff members and no certified developers in the corresponding field. Fairsoft’s site names a core team of three: Sue as lead developer and principal, Asa as product development consultant, and founder Tom. These two records broadly align on size, although the certification field may reflect listing status rather than the full competence of the team. Fairsoft also describes a wider network, but publishes no roster or coverage arrangement.

A small team can be a strength. The people who discover the workflow may also design, build and support it. Communication can be direct. Decisions need not cross several departments. Long tenure can preserve customer context. Fairsoft’s claimed history suggests unusually deep familiarity with legacy database conversion and long-lived small-business systems.

The same concentration creates key-person risk. If one person holds most application knowledge, a holiday, illness, retirement or competing incident can affect delivery and support. If the lead developer also operates hosting, approves changes and knows the encryption credentials, several control functions converge. A buyer should evaluate the service as a small critical supplier, not pretend it has large-company redundancy.

Continuity evidence should be concrete. Ask which two people can administer production, restore a backup, modify every major script, renew certificates and support each integration. Ask how on-call coverage works and whether another Claris partner can step in. Require a current runbook, architecture map, credential inventory, release history, known-issue list and support log. Schedule periodic handover sessions to a customer administrator or named substitute.

Claris says its ecosystem includes more than 1,400 partners. That makes substitute capability plausible, but not automatic. Another developer may be able to open a well-documented FileMaker file and still need weeks to understand custom behaviour, business exceptions and third-party connections. Portability improves when documentation, full access, naming discipline, test data and release records are maintained from the start.

An escrow arrangement may help where the customer cannot continuously hold everything, but ordinary possession is often better. The customer can receive each released FileMaker file, documentation and export without waiting for a trigger. If any proprietary Fairsoft utility or reusable component cannot be delivered, the agreement should define a licence broad enough for continued operation and modification, plus an escrow trigger for insolvency, abandonment, prolonged support failure or termination.

The succession question should also be personal and corporate. Who takes over if the principal cannot serve? Can the Canadian corporation assign the agreement without consent? Does a change of control permit termination and data return? Are prepaid hosting fees protected? The public identity history makes these normal questions especially important.

The real price is development plus the right to keep operating

Fairsoft does not publish current project, hosting or support prices. Claris publishes a platform structure: its cloud pricing page describes per-user annual billing, separate Starter and Max limits, storage and API allowances, and a different path for larger deployments. Self-hosting can involve annual or perpetual platform licensing, hardware, system administration and optional resilience services. A Fairsoft quote should separate these costs so the buyer can see which price belongs to which provider.

The first cost is discovery and development. A fixed fee may make the initial budget legible, but it can contain contingency for unknowns or tightly constrain change. The second is conversion: extraction, cleanup, reconciliation, rehearsal and cutover. The third is platform licensing, usually connected to users, access patterns or deployment. The fourth is hosting and operation. The fifth is integrations, which may carry their own subscriptions and maintenance. The sixth is support and enhancement. The seventh is exit.

The cost curve matters more than the opening quote. A bespoke system becomes expensive to replace as it absorbs exceptions, history and integrations. Enhancement prices may look modest individually while cumulative changes make the application harder for another supplier to understand. Platform upgrades can require testing. A new operating system, accounting interface or browser can create work even when the business asks for no new feature.

The quote should therefore include a five-year total-cost view with explicit assumptions: user counts, storage growth, API use, support hours, expected enhancements, platform upgrades, backup and standby options, certificate costs, third-party services, training and termination assistance. It should show renewal dates and price-adjustment rules. If Fairsoft resells licences, the buyer should know whether it can move those licences to a direct Claris relationship or another reseller.

Change pricing needs a unit the buyer can govern. Hourly rates are useful even inside a fixed-fee project because they reveal the cost of excluded work. Small enhancements can use a capped estimate; larger ones can use another discovery and acceptance cycle. Emergency work should have a defined premium. Unused support hours, minimum commitments and response targets should be visible.

Exit is not a penalty to discuss after trust has broken. Price it at the beginning: final backup, self-contained copies, platform-neutral exports, documentation refresh, credential transfer, knowledge sessions, assistance to a successor and certified deletion after acceptance. A supplier confident in its service should be able to make leaving orderly.

FileMaker export is necessary but not application portability

Claris supports useful extraction routes. Its format guide lists CSV, Excel, XML, DBF and other formats, and FileMaker can expose information through ODBC, JDBC and web interfaces. Its copying guidance distinguishes a normal copy, an empty clone and a self-contained copy that embeds externally stored container content. These are valuable tools for preservation and transition.

But a row export does not carry layouts, scripts, calculations, reports, access rules, scheduled tasks, plug-ins or integration behaviour into a replacement platform. A .fmp12 file can preserve much of the working application, but only for someone with compatible FileMaker software, adequate credentials and the knowledge to operate it. A self-contained copy can bring attachments inside the file; a casual copy may omit externally stored container content. Portability is therefore a set of deliverables, not a single export button.

The customer should receive four forms of continuity material.

First, a recoverable application set: every FileMaker file, external container, configuration file, plug-in and required certificate, with checksums and a restore guide. Second, platform-neutral information: documented exports of core tables and attachments, including field definitions, relationships, code lists and reconciliation totals. Third, operational knowledge: system map, scripts and schedules catalogue, integration contracts, support procedures, release notes and known defects.

Fourth, authority: full-access credentials, encryption passwords, licence records, domain and service-account control, and intellectual-property rights sufficient to use, copy, maintain and commission changes.

Intellectual-property wording must be specific. The customer may own bespoke work but only receive a licence to Fairsoft’s pre-existing utilities, templates or know-how. Third-party plug-ins may have separate terms. The agreement should identify each category and state what a successor can use. “Customer owns its data” is not enough if the successor cannot lawfully operate or modify the application.

An exit rehearsal turns these words into evidence. Give a clean machine and the handover pack to a qualified person who did not build the system. Ask that person to identify the files, restore a non-production copy, sign in with customer-controlled credentials, run core workflows, export essential information and describe missing dependencies. Time the exercise. Correct the pack while the original team is available.

The Government of Canada’s cloud selection guidance treats exit planning as part of business continuity and notes that differentiated software services are harder to move than commodity infrastructure. That principle applies even to a modest FileMaker installation. The smaller the buyer, the less spare capacity it has for an emergency migration.

Competition begins with choosing the kind of dependence

Fairsoft should not be compared only with another bespoke developer. The buyer has at least five strategic choices.

It can keep spreadsheets and manual work. That avoids a platform migration but preserves key-person knowledge, weak controls and repeated effort. It can buy an off-the-shelf industry service. That may offer broader support and regular updates, but the business may need to change its workflow and accept the provider’s roadmap. It can use another low-code environment, such as Microsoft Power Apps; Microsoft’s pricing page shows its own per-user licensing and Dataverse capacity structure, illustrating that a different platform changes rather than removes dependence. It can commission another FileMaker partner. Or it can build and operate a system internally.

Fairsoft’s likely advantage is the combination of legacy conversion, direct senior attention, iterative discovery and one supplier for development, hosting and support. Its likely procurement challenge is the evidence burden created by a small team, a dated public site and an unresolved legal succession step. These are not verdicts on delivery quality. They are the dimensions on which a buyer should compare bids.

Comparing another FileMaker partner is particularly useful because it separates platform choice from supplier choice. Ask two or three partners to review the same workflow and exit requirements. Compare discovery depth, named staff, certification, architecture, testing, security, support coverage, documentation, recovery and price. Claris’s directory includes many alternatives, and its own disclaimer makes clear that selection remains the customer’s responsibility.

Comparing an off-the-shelf product tests whether uniqueness is real. A workflow may feel special because it grew through years of exceptions, not because every exception creates value. Before automating it, ask which steps are legally required, competitively important or simply habitual. Fairsoft’s iterative approach can help expose that distinction, but the buyer must be willing to retire unnecessary variation.

The final choice should be framed as controlled dependence. Every useful business system creates dependence on software, people and operating practices. The goal is not zero lock-in. It is a dependency whose price, controls, alternatives and exit time are understood.

The procurement test Fairsoft should be invited to pass

A disciplined buyer can convert the evidence gaps into a practical request rather than a vague risk score.

1. Prove the counterparty. Ask the proposal to name the legal company, corporation number, notice address, governing law, tax identity and payee. For any continuing Massachusetts-era obligation, request the assignment or novation chain. Confirm who owns or licenses the Fairsoft name and any reusable component needed for the work.

2. Demonstrate discovery on one hard workflow. Choose an exception-heavy process, not the happy path. Ask Fairsoft to map actors, information, decisions, failure points and desired outcome. Evaluate the questions it asks, not the polish of a sample screen.

3. Define the approval loop. Require separate labels for feedback, decision, test completion and contractual acceptance. Every accepted item should point to test data and expected results. Record assumptions, defects and deferred work. Name the person authorized to approve.

4. Reconcile price and scope. Ask whether the fee fixes outcomes, functions, iterations, effort or schedule. List exclusions and third-party charges. Define how reprioritization and change work. Tie payments to evidence, including documentation and handover.

5. Make conversion auditable. Require a source inventory, mapping, repeatable conversion process, control totals, exception handling, rehearsal, cutover and rollback plan. Preserve the original information and prove that attachments, history and key business rules survive.

6. Expose the architecture. Obtain the file and integration map, version list, plug-ins, service accounts, scheduled tasks, data locations and ownership boundary. Identify anything that only one person understands.

7. Test security rather than accept adjectives. Ask for the hosting route, supported versions, patch evidence, encryption configuration, certificate status, role matrix, multi-factor capability, logs, component inventory, vulnerability process and recent independent assurance where available. Run least-privilege tests on representative roles.

8. Restore the service. Witness restoration from a selected backup and measure information loss and elapsed time. Confirm offsite separation, retention and customer access to copies. Ask whether the 2026 remote-backup and standby options are used, and if not, what provides equivalent resilience.

9. Test the support bench. Meet the named primary and backup staff. Walk through a severity-one scenario outside normal hours. Review response targets, escalation, maintenance notice and substitute-provider arrangements.

10. Protect privacy and compliance. Complete a data-flow and sensitivity assessment. Sign a processing schedule covering location, subprocessors, use, access, retention, return, deletion, audit and incident cooperation. Add sector-specific requirements where the application handles regulated information.

11. Rehearse exit before go-live. Deliver full-access and encryption credentials to a customer-controlled vault, restore a customer-held copy, produce neutral exports and attachments, and have an independent FileMaker professional assess the handover pack. Fix gaps before final payment.

12. Price the operating life. Compare five-year development, licence, hosting, support, upgrade, integration and exit costs. State renewal and price-adjustment rules. Confirm whether licences and hosted files can move to another provider.

This test is demanding but proportionate. A three-person supplier should not be expected to produce the bureaucracy of a multinational. It should be able to show who is responsible, how work is accepted, how information is protected, how service resumes and how the customer leaves.

Evidence gaps and watchpoints

Fairsoft’s public footprint is coherent enough to establish the business but too sparse to underwrite a critical system on its own. The strongest evidence is the combination of the current site, the Claris listing, the Canadian federal register and the BBB linkage. The most important unresolved evidence is the legal bridge from the historical Massachusetts company to the Canadian corporation.

The site’s age is both signal and noise. Old FileMaker version references and a 2011 pricing statement show long history, but they make it difficult to know which commercial and technical claims are current. The 2026 copyright footer proves maintenance of the page, not refresh of every paragraph. Named customer examples and cumulative customer counts remain company claims unless current references confirm them.

No public Fairsoft service-level agreement, standard customer terms, data-processing terms, current price card, infrastructure description, security assurance report, subprocessor list, disaster-recovery test, certification evidence, accessibility statement or succession plan was found. No credible Fairsoft-specific incident was found either. Buyers should request these items privately and distinguish “not published” from “does not exist.”

Several watchpoints deserve an annual check:

• the active status, directors, significant-control disclosure, registered office and filings of Canadian corporation 1020680-6;
• the identity of the company shown on proposals, invoices, hosting notices and bank instructions;
• Claris partner status, staff and certification entries;
• FileMaker server and client versions, security fixes and deprecated features;
• the named support bench and coverage for the lead developer;
• backup completion, independent restoration results and actual recovery times;
• the customer’s ability to open a current copy with its own credentials;
• the completeness and reconciliation of platform-neutral exports;
• changes in hosting location, subprocessors, integrations and data sensitivity;
• five-year cost against an off-the-shelf service, another FileMaker partner and a managed internal build.

The investment case for Fairsoft is not that bespoke software eliminates dependence. It is that a small, experienced team may be able to remove highly specific workflow friction faster and with more empathy than a standard product. The risk case is that the resulting system can bind a customer simultaneously to a legal counterparty, a few people, a host and a proprietary platform.

That trade can be rational. Fairsoft’s iterative practice creates frequent opportunities to discover what matters. The buyer’s job is to use those same opportunities to accumulate control: a signed decision, a passing test, a reconciled conversion, a restored backup, a second support path and an export that another party can understand. When every loop leaves the customer more capable of operating and leaving, custom software becomes institutional infrastructure. When every loop leaves knowledge and authority with the supplier, approval is merely the mechanism by which lock-in is accepted one screen at a time.