CompensationAtlas and TaxAssessmentIQ look, on the surface, like two unrelated products. Underneath, they're the same thing wearing two different faces.
It would be easy to treat each new dataset as its own standalone app. That's the more obvious path, and it's the wrong one — every dataset describes the same underlying city, already connected in the real world.
Everything sits on one Intelligence Engine: a shared layer of open-data connectors, a knowledge graph, and the prediction models that read relationships across all of it.
In twenty years, I think people will say, "I asked ALKARTIS," not "I used CompensationAtlas."
A permit can be an early signal of new housing. New housing can shift who's registered to vote nearby. None of these facts matter much in isolation — they matter because they're connected.
Building each product as an isolated app might look faster at first, but every new dataset would require rebuilding the same ingestion, cleaning, and connection logic from scratch. The shared engine is what makes the fourth and fifth product faster to ship than the first and second were.
Right now, that means five live applications and a real, working engine underneath them. The roadmap is exactly that — a roadmap, not a promise with a date attached.
LandlordEye, BlockWatcher, and BuildSignal all plugged into the same connectors and knowledge graph already powering CompensationAtlas and TaxAssessmentIQ — new lenses on existing infrastructure, not new infrastructure. ContractSignal and ListingIQ, still in development, are built the same way.
Pricing tiers are structured around access to the growing product set — see Pricing for current plans.
API access to the underlying engine is available on Government & Enterprise plans.
Because the underlying data is already connected in reality — payroll, permits, and assessments all describe the same city. Treating them as separate silos would mean rebuilding the same work five times.