A smart feeder can pass every bench test and still disappoint a customer years later. The motor runs, the lid seals, the portions drop. Then an app update, a cloud policy change or an expired license turns a working appliance into a support ticket.
Firmware is the part of the purchase that does not appear on a QC report. It needs its own terms, written before the hardware order is placed.
The support clock starts after the last carton
QC tests the unit in front of it. Firmware support is a promise about behavior after the unit leaves. The risk peaks after the last production run, when engineering attention has moved to the next model and the old SKU still sits in a warehouse or on a retail shelf.
That is why the first question is not "is the app good?" It is "how long after the last shipment will you fix a critical bug, and what counts as critical?" A supplier can answer with a number of years, a severity definition and a named owner, or with "we support our products," which is not enforceable.
A product can also reach end-of-life while cartons are still in the channel. The end-of-life notice is the clause that gives the retailer time to sell through, warn customers or plan a replacement. Without it, the first notice is often the app failing to connect.
Who owns the code, the app and the keys
Three assets decide the balance of power. The firmware may sit in a factory codebase the buyer licenses but never owns. The private-label app is usually a license with a term, a renewal price and a termination clause, not software the buyer can keep forever. The OTA signing keys decide who can push an update and who can recover a unit bricked by a bad release.
Ask for the license document and a short IP summary before the deposit. Check what happens at the end of the term: does the app stop, renew at a new price, or transfer? Ask who holds the keys and what happens if the factory changes its platform provider. Assume the purchase includes the software and you will discover the gap later.
The 6L smart pet feeder with app control is a good example of a product whose value depends on both halves. The hopper and the motor are visible. The app, the cloud account and the update path are not, which is exactly why they need to be in the contract.
Five clauses for a one-page annex
A firmware annex does not need to be a software license agreement. It needs five headings and enough specificity that both sides can tell whether the promise was kept.
Support window. State how many years after the last shipment the supplier will fix bugs and ship security patches. Separate security fixes from feature updates; a supplier may commit to one, not both. Define critical: a device that cannot pair, cannot dispense or cannot be recovered is a different severity from a cosmetic app issue.
Bug-fix service level. Name severity levels and response or fix days. Say who pays for the engineering work and who deploys the update. A promise to "fix bugs" without a clock is a sentiment.
OTA cadence. Agree how often security patches are expected, who approves a release before it reaches customers, and what the recovery path is if an update fails. If the update depends on a cloud service, say who pays for that service and what happens if the bill is not paid.
Data export and migration. If the platform closes, feeding schedules, device settings and user accounts should leave in a machine-readable format. Name the destination and the notice period. A local fallback that keeps the feeder dispensing on its last schedule turns a shutdown into a degraded product.
End-of-life notice. Require written notice before support ends, with a last-update date and a statement of what will still work offline. The notice period should be long enough to sell through stock, not just long enough to send an email.
If the supplier already has an annex, mark it up rather than drafting from zero. The point is a signed page, not a negotiation ritual.
Tuya is not the same risk as a factory cloud
A Tuya-based product runs on a large third-party platform with an existing app and cloud. The supply-cut risk is lower than with a single small factory, but the rule-change risk is real. API pricing, app-store policy and feature deprecation can all move after launch. The mitigation is contractual: name the platform version and SDK in the specification, require written notice before a breaking change, and keep a migration path on paper.
A proprietary or factory-hosted cloud gives the buyer more control, but it also makes the buyer dependent on the factory's software team. If the factory exits the category or loses the engineer who built the app, the product can lose its backend. Ask for source-code escrow or a build handover as a fallback. Neither option is automatically safer; the right choice depends on whether the buyer has the capability to operate software, not just the ambition to own it.
The 4L automatic feeder with Tuya app control and the WiFi feeder with camera sit on different parts of this spectrum. The questions are the same even when the stack is different.
Put the annex in the PO, not the brochure
Send the annex with the RFQ and ask the supplier to mark exceptions. A supplier that edits the page is engaging with it; a supplier that sends a brochure with the word "lifetime" is avoiding the question. Once both sides agree, attach the annex to the purchase order and keep the signed copy with the SKU file.
The software question applies at every order size: OEM starts at 1,000 units, ODM at 3,000, and a private-label trial at 50. Scope the firmware terms with the tooling and packaging, because a support promise added after launch is a renegotiation.
Beware the word "lifetime." Ask whose lifetime: the product, the app, the platform or the company. A term with no definition is not a commitment. A number of years, a severity table and a notice period are.
What the retailer pays when support stops
When the app stops working, the customer does not call the factory. They call the retailer or the support line on the box. The retailer absorbs the ticket, the return and the review even though the code belongs to someone else. That is the commercial reason to negotiate firmware terms at the buying stage rather than the claims stage.
Price the annex as part of the landed cost, not as a legal extra. Compare it with the cost of one support cycle, one returns batch or one relaunch. The annex is usually the cheaper line, and it is the only one that gives the buyer a document to point to when the platform changes direction.
A roadmap is a plan; the annex is the commitment. Ask for support commitments, not feature promises. The question is not whether the app is good on launch day. It is who answers when it breaks years later.
Questions to settle before the annex is signed
Who owns the firmware in an OEM program?
The firmware in the feeder board usually stays with the factory unless the purchase order assigns rights. The private-label app is typically a license with a term, and the OTA signing keys may stay with the factory or the platform. Ask for an IP summary that names each asset, the owner, the license term and the transfer conditions.
How long should a firmware support window last?
Match it to the service life you expect and the warranty you offer, then define what is covered. Security patches and critical bug fixes should run for the full window; feature updates can end earlier. The definition and the remedy matter more than the number.
What happens to users if a platform shuts down?
That depends on the clauses. A data-export clause gets schedules and accounts out in a usable format. A migration clause names where they go. A local fallback keeps the device doing its core job without the cloud. A notice clause gives the retailer time to tell customers. Ask for all four, and test the fallback before the first order ships.
If you are sourcing a connected SKU, ask for the firmware annex with the quote. We will quote the hardware and mark the software terms we can support in writing, so the support question is settled before the tooling starts.
