The layer beneath, and the apps above it.

Neutrinos Platforms, Inc.

An operating system, a platform, and a framework for building and delivering a suite of apps across every device — privacy-first, and powered by a full on-device large model.

Neutrinos Platforms takes its name from the particle that passes through almost everything without disturbing it. That is not decoration. It is the company's argument about how software should relate to the people who use it: intelligence that moves through your life without leaving residue behind, doing its work where your content already lives rather than shipping that content somewhere else to be processed, monetized, and retained.

The company describes itself in three layers, and the distinction between them matters more than it might first appear. As an operating system, Neutrinos is a coherent runtime that hosts applications and their intelligence, consistent from a phone to a laptop to the edge — so that an app behaves like the same app wherever it runs, rather than like three separate products that happen to share a logo. As a platform, it supplies the shared services every app in the suite plugs into: identity, synchronization, and on-device AI. As a framework, it offers one set of primitives for building and delivering across devices and platforms, so that an idea is expressed once and shipped everywhere.

The reason to separate those three is that most software companies conflate them and pay for it later. A framework without a platform produces apps that each reinvent accounts and sync. A platform without an operating system produces a fleet of clients that drift apart in feel and capability. Neutrinos' bet is that when the three are designed together, capabilities compound instead of fragmenting — a feature built once for the platform becomes available to every app above it, rather than being reimplemented, slightly differently, in each.

Privacy as architecture, not policy

The company's most load-bearing claim is that privacy is architectural rather than contractual. The distinction is worth stating precisely, because the industry has trained everyone to hear it as marketing. A privacy policy is a promise about what a company will choose to do with data it has already collected and can already read. An architecture is a statement about what is possible at all. When a full large model runs locally, the intelligence in a product — the classification, the ranking, the extraction, the summarization — happens on hardware the user owns, against content that never left it. There is no cloud middleman to trust, audit, or subpoena, because there is no cloud middleman in the path.

This shows up concretely in the shipping products. Classify makes no use of advertising identifiers and runs no third-party tracking; Apple's App Tracking Transparency prompt does not appear in it, because there is nothing to ask permission for. Top Deals computes its price judgments — whether the current price is genuinely good, how it compares to what the item has historically cost — on the device, from data the app already holds, rather than by sending a shopper's browsing to a server that profiles them. In both cases the privacy property is a consequence of where the computation happens, which is the only kind of privacy guarantee that survives a change of management.

The trade-off is real and worth naming: on-device intelligence is bounded by the device. It cannot draw on a global view of every user's behavior, and it cannot be silently upgraded by swapping a model on a server. Neutrinos treats that as an acceptable price, on the theory that most of the intelligence people actually want from their software is local by nature — what is in this photo, what is this listing, is this a good price, what did I save last week — and does not require the rest of the world's data to answer well.

Neutrino Labs, Inc.

The name on the App Store records, the signing certificates, and the release engineering — the operational half of the same enterprise.

Where Neutrinos Platforms is the identity that appears on the platform's own site and in Classify's product footer, Neutrino Labs, Inc. is the entity that appears in the machinery of shipping: it is the Apple Developer team that holds the App Store records and bundle identifiers for the suite, including classify.app and app.topdeals, alongside other properties in development. In practice the division reads as platform identity on one side and product delivery on the other — one side defines the architecture, the other signs, notarizes, provisions, and releases against it.

That may sound like an administrative footnote. It is not, and anyone evaluating a small software company should look closely at exactly this seam, because it is where most of them bleed time. Shipping Apple software at this level means maintaining App IDs and their capabilities, iCloud containers, App Groups, push environments, associated-domain entitlements, signing certificates, provisioning profiles across development and distribution, notarization for the Mac, and the review process for every platform, for every release. Each of those is a place where an unnoticed mismatch produces a build that compiles perfectly and then fails silently on a user's machine — an app that launches and cannot sync, a shared link that opens a browser instead of the app, an entitlement stripped at signing time that takes the whole feature with it.

The response has been to treat release engineering as a first-class engineering surface rather than a chore performed by hand at the end of a cycle. Developer-portal state is inspected and modified programmatically through the App Store Connect API rather than clicked through a web console from memory; capabilities are enabled deliberately and verified before the entitlement that depends on them is added; signing paths for local verification and for distribution are kept separate and explicitly documented, because the reduced entitlement set that lets a developer run a build locally is emphatically not the set that should ship. The recurring lesson, learned the expensive way, is that Apple's platform fails quiet: a wrong team identifier, a retired capability, an entitlement that was never provisioned will not usually announce itself with an error. It will simply not work, for everyone except the developer who tested it.

The practical upshot for a partner or an acquirer is that the operational substrate here is unusually well understood for a company of this size. The number of people who can reliably take a multiplatform Swift application — macOS, iPadOS, and iOS from one target — through CloudKit schema deployment, capability provisioning, notarization, and App Review is small, and that competence is not visible in a screenshot.

Classify

A powerful classifier built to share, explore, and discover your interests across platforms — an intelligent space that is social when you want it and completely private when you do not.

Classify is the platform's flagship and its proof. On the surface it reads as a marketplace: a feed of listings with photographs, prices, and locations, organized into nine categories that describe how people actually use classifieds — Community, Diners, Events, Foods, For Sale, Gigs, Housing, Jobs, and Services. You browse a feed, narrow it by category or classification, filter by price, search, open a listing, save it, discuss it, and either message the poster or follow the listing out to wherever it lives. You can post your own in a few fields.

Underneath, the more interesting claim is in the name. Classify is built around the premise that the useful primitive is not the listing but the classification — the act of deciding what a thing is, which category and sub-category it belongs to, what it is worth, and whether it is relevant to you here and now. That is exactly the kind of judgment an on-device model is well suited to make, and it is the connective tissue between a marketplace and the broader "share, explore, and discover your interests" ambition the platform describes. A marketplace is simply the most legible first application of a classifier that can look at content and place it correctly.

The desktop app is a browser

The Mac version makes a design decision worth calling out, because it is unusual and it is deliberate: a Classify window behaves like a browser tab. Each window carries its own navigation state and history, windows group into native tab bars, and a single unified toolbar carries an omnibox that serves as address bar, search field, and command line at once. The effect is that a Mac user does not learn a new interaction model — they already know this one — while the app retains native performance, native sync, and native system integration that a website cannot reach.

The marketplace is the first legible application of a classifier that can look at content and place it correctly.

Location, without surveillance

Classify is location-aware in the way a classifieds product has to be: the feed can be scoped to Nearby or Everywhere, a place picker lets you set where "nearby" means, and listings carry the region and approximate area they came from, with distances computed against your chosen place. The distinction the product draws is between using a location and retaining a person's movements. The app asks for a location in order to sort a feed, and the answer is a place, not a trail.

The web mirror

classify.app is not a marketing page with a download button. It is the application, rendered for the browser: the same feed, the same categories and filters, the same listing detail with its photo gallery and its outbound link, and the ability to post. It is deliberately built as a single self-contained page of vanilla HTML, CSS, and JavaScript — no framework, no build step, no dependency graph to rot — served by a small edge worker that talks to exactly the same production data store the native apps use. A visitor sees real listings, not a screenshot of them.

That worker does the one thing a browser cannot do safely: it authenticates to the backing store server-side, signing each request with a key that never reaches the page. It is a small piece of architecture with a large consequence — the public web gets first-class access to live data without the app's credentials ever being exposed to it.

Every listing has its own address. Opening a listing puts a shareable URL in the browser's address bar; the share control hands that link to the system share sheet on iOS and Android; and when the link is pasted into a message it unfurls with the listing's real title, price, and photograph, because the edge worker looks the record up and writes those details into the page before it is served. The same path is claimed by the native app, so a shared link opens Classify where Classify is installed and the website where it is not.

Top Deals

Hand-tracked discounts and coupons across your favorite stores, ranked by real savings and real ratings — not just by the biggest number on the tag.

Top Deals is a deals and coupons aggregator, and it begins from a complaint about the category it belongs to. The economics of deal sites reward the largest visible percentage, which is why they are full of items marked down from prices nobody ever paid. A "70% off" badge is trivially manufactured by inflating the reference price, and every shopper has learned to distrust it without quite being able to check it.

Top Deals' answer is to rank on something harder to fake. Its ordering blends the actual saving against a validated reference price, the retailer's own rating and review volume, and engagement — and it discards implausible reference prices outright rather than passing them through to look impressive. A deal that claims a discount steeper than the catalog considers credible is treated as a parsing error, not a bargain. The visible result is a feed where the top item is usually a genuinely good price on something people actually rate well, rather than the most aggressively marked-up item in the catalog.

Desktop first, on purpose

Most shopping software is designed for a phone and then stretched onto larger screens. Top Deals inverts that. It was built desktop-first, as a proper Mac application with a sidebar, a multi-column grid, an inspector panel, and a menu-bar companion that sits quietly in the corner of the screen, shows how many deals are being tracked and what the best discount currently is, refreshes itself on a schedule, and tells you when something genuinely new has appeared. Deal-hunting is a background activity that happens while you are doing something else, and the menu bar is the correct home for a background activity on a Mac.

The phone and tablet versions are not afterthoughts — the same single multiplatform target produces all three, and the interface adapts rather than being redrawn — but the center of gravity is the desktop, which is where people actually compare prices, open several tabs, and decide.

A discount steeper than the catalog considers credible is treated as a parsing error, not a bargain.

Price intelligence, locally

The feature that distinguishes the product is the one a retailer will never build: an honest answer to "is this actually a good price?" Top Deals records a price point every time it sees an item, builds a history, and computes a verdict from it — the current price against the lowest, average, and highest it has tracked — presented as a plain judgment with the reasoning available behind it, including a chart of the history. Price alerts let a shopper name a target and be notified when it is met, once, without being pestered again at the same price.

All of it happens on the device, from data the app already holds. The app does not need to know who you are to tell you whether a price is good, and it does not build a profile in order to answer.

Where the catalog comes from

The catalog is assembled by the desktop app itself, which loads retailers' best-seller and deals pages in an off-screen browser view and extracts one product per card — title, image, link, current price, reference price, rating, and review count. The results are deduplicated by retailer product identity, so the same item arriving from several sources appears once, and merged into the local catalog, which then syncs outward. A companion pipeline runs the same extraction offline for bulk refreshes.

This is more fragile than an affiliate feed and it is chosen deliberately, because it produces a catalog that reflects what is actually on the shelf today rather than what a network published this week. The maintenance cost is real: retailers rebuild their markup without warning and retire category identifiers silently, and when they do, a scraper does not throw an error — it simply returns nothing, and the failure is invisible until someone notices that a whole retailer has stopped appearing. The engineering discipline the product has had to develop in response is monitoring for silence, and treating a source that suddenly returns zero as an incident rather than as a quiet day.

Like Classify, Top Deals mirrors itself to the web. topdeals.app serves the live catalog with the same ranking the app uses, every deal has its own shareable address, searches are shareable too, and signed-in users get a private page of their own saved deals and price alerts at an unguessable link — their data on the web without an account on the web.

What the two products have in common

Two very different applications, built from one set of decisions — which is the whole argument for having a platform underneath.

Classify and Top Deals look nothing alike and serve unrelated needs. A marketplace and a price tracker share no screens. What they share is everything below the screens, and the degree of that overlap is the practical evidence for the platform thesis.

• Local-first data with real sync. Both keep a local database as the source of truth for the interface and synchronize it against a cloud store, with the server's record metadata preserved on each object so conflicts resolve correctly. Both open, browse, and work with no network and no account.
• One identity. Sign in with Apple, and nothing else. No password to create, no email to verify, no profile to complete before being allowed to look around. Signing in is what makes data follow you between devices; it is not the toll gate at the entrance.
• One multiplatform target. Each product is a single build producing Mac, iPad, and iPhone applications, with the great majority of logic and interface living in a shared Swift package and only a thin shell in the app target.
• A web mirror served from the edge. Both sites are self-contained vanilla pages served by small workers that hold the credentials server-side, showing live production data rather than marketing screenshots.
• Addressable content. Every listing and every deal has a canonical URL that is claimed by the native app, opens the website when the app is absent, and unfurls with a real title, price, and image when it is shared.
• No advertising surveillance. Neither product carries third-party ad tracking. Where Classify shows promoted listings, the inventory is Classify's own.

The compounding is visible in how quickly a capability crosses the suite. Shareable per-item links, canonical URLs, system share sheets, and rich link previews were designed once and landed in both products and both websites in the same working session, because the shape of the problem — an item, an identifier, a URL, a native claim on that URL, a server-side preview — was identical in both. That is what a platform is for.

How it is built

A small number of strong convictions about software, applied consistently enough that they show in the product.

1. Native, current, and unhedged. Both apps are written in Swift with strict concurrency and target the current OS generation directly, using the current design system as it was intended rather than approximating it. There is no cross-platform abstraction layer and no compatibility floor being dragged along. The cost is that the apps require recent systems; the benefit is that they look and behave like software built for the machine it is running on.
2. The package is the product. In each app, the Xcode target is deliberately tiny — an entry point, a delegate, entitlements, assets — and everything else lives in a local Swift package that can be built, previewed, and unit-tested on its own. The interface is testable, the logic is testable, and the app target is too small to hide anything.
3. Degrade quietly, never worse. A recurring rule: a capability that fails must leave the product no worse than if it had never been attempted. Cloud sync is gated on the entitlement actually being present and falls back to local-only. Server-side search falls back to a simpler query and then to local search. A link preview that cannot be built serves the ordinary page. The user-visible failure mode of an unavailable feature is its absence, not an error.
4. The web is the app, not a poster. Both sites render live production data through an edge worker that holds the credentials. Neither is a framework application; both are single self-contained pages, which is a considered choice about what will still build and deploy without incident several years from now.
5. Verify against the real thing. Extraction logic is checked against live retailer pages, not fixtures, because the failure being defended against is precisely that the live page changed. Interfaces are driven and screenshotted on real devices and simulators. A test suite covers the logic that can be pinned down; the parts that depend on the outside world are checked against the outside world.
6. Write down what was expensive to learn. The failures worth documenting are the silent ones — the retired identifier, the entitlement stripped at signing, the selector that now matches nothing, the cap that quietly ended ingestion. Each is cheap to fix and extremely expensive to rediscover, and the institutional memory of a small team is the difference between a two-minute fix and a two-week mystery.

What is ahead

Two shipping products, a platform argument they are meant to demonstrate, and the specific work that would extend it.

Read plainly, the enterprise is a platform company with two consumer applications in the market that serve as its evidence. Classify is the flagship and the one that carries the platform's central idea — a classifier that understands content well enough to place it, applied first to a marketplace and intended to reach further into "share, explore, and discover your interests." Top Deals is a focused, self-contained product in a category with obvious commercial mechanics, and it doubles as a demanding test of the platform's data, sync, and ingestion layers, because a deals catalog changes continuously and unforgivingly.

The honest assessment of where the work stands is that the platform's shared spine is real and demonstrated — identity, local-first sync, multiplatform delivery, edge-served web mirrors, and addressable shareable content all exist in both products and were built once — while the most distinctive part of the thesis, the full on-device large model as the intelligence layer every app draws on, is the frontier rather than the foundation. Classification, ranking, and extraction today lean on well-chosen deterministic logic with on-device intelligence layered where it earns its place. That is the right order of operations. A ranking function that can be explained to a shopper is worth more than one that cannot, and it establishes the baseline any model has to beat.

The near-term work follows the same logic that produced the shared spine: find the capability that both products need, build it once, and let it compound. Search is the current example — recently rebuilt to tokenize a query properly, require every word to match, and rank by where each word lands, implemented identically in the native app, the website, and the public endpoint so all three agree. Ingestion breadth is another, where the discipline is less about clever extraction than about noticing quickly when a source goes quiet.

What a partner or an acquirer would be evaluating, in the end, is not a feature list. It is a small team's demonstrated ability to take an opinionated architectural position — intelligence on the device, one platform beneath many apps, the web as a first-class rendering of the same product — and actually ship it, on Apple's platforms, through review, to the App Store, twice, with the operational competence that requires and the restraint to let a capability degrade quietly rather than fail loudly.