Project examples
Software that shipped
Three products designed, built, launched, and operated by the same principal who would lead an agency engagement.
Stated plainly. These are products Bellcourt Systems funded and built for itself. No client commissioned them, and we do not present them as client engagements. Many solicitations ask for examples of relevant projects, which these satisfy; where a solicitation requires prior contracts of comparable value or prior government clients specifically, we say so rather than blurring the distinction. A procurement officer who checks finds out either way, so we would rather be the one to tell you.
Tractimus
Tractimus runs a production large-language-model stack against real estate workflows. The engineering interest is less the model than everything around it: routing across providers, controlling which vendors may retain data, handling failure without stranding the user, and keeping cost predictable under load.
That is the part that matters for government work. An agency evaluating applied AI is rarely asking whether a model can draft text. It is asking who can see the data, what happens when the service is unavailable, and whether a human remains accountable for the decision. This system was built to answer those questions.
Directly transferable
- Large-language-model integration with provider routing and fallback control
- Data-handling constraints, including zero-retention and no-training provider settings
- Document classification, extraction, and drafting with a preserved human decision point
- Cost control and predictability under variable load
WeCryptAI
WeCryptAI is an encrypted messaging application that integrates with the contacts already on a user's phone. Building it meant working through key generation and storage, the contact-matching problem without exposing a user's address book, and the mobile platform constraints that govern both.
Its language model runs in either of two places: on the device itself, or in the cloud. That is a deliberate architectural choice rather than a configuration detail, because it is what determines who can see the data.
Why that matters for government
Agencies evaluating anything with AI in it eventually arrive at the same question, and it is rarely about model quality. It is whether resident data, case files, or communications leave the agency's boundary — and if so, whose servers they land on, under which jurisdiction, and subject to what retention.
On-device inference answers that question by removing it. The content never leaves the handset, so there is no third-party processor to assess, no cross-border transfer to justify, and no vendor retention policy to take on trust. Where a workload genuinely needs cloud scale, the same system runs there instead — but the agency decides which, per workload, rather than inheriting the vendor's decision.
Security work is the least visible line on a proposal and the most consequential after award. Any system holding resident records, case files, or payment data inherits these questions, and having built to them is different from having read about them.
Directly transferable
- On-device model inference, keeping sensitive content inside the boundary
- Data-sovereignty architecture — a per-workload choice between local and cloud processing
- Applied cryptography and key management
- Privacy-preserving handling of sensitive user data
- Mobile platform integration and permissions
- Secure-by-default architecture rather than security added late
playBYapp
playBYapp combines a social identity layer for athletes with a working reservation system: scheduling, capacity limits, booking flows, and the state management that keeps them consistent when several people book at once.
Of the three products, this is the one that maps most directly onto public-sector scope. Municipal parks and recreation systems, community program registration, and facility booking are the same problem — a finite resource, a calendar, eligibility rules, and a public that expects to complete the transaction without calling anyone.
Directly transferable
- Reservation and scheduling engine with capacity enforcement
- Waitlist behaviour and allocation when demand exceeds supply
- User identity, registration, and profile management
- Administrative views for staff who are not developers
References
Users of these products are available to speak to delivered, operating software on request. They are users of a product Bellcourt Systems built — not clients who commissioned and paid for the work — and we describe them that way in every proposal.
This satisfies reference sections asking for contacts who can speak to software delivered. It does not satisfy sections requiring prior government clients or prior contracts of comparable value, and we will tell you directly when a solicitation asks for something we cannot yet supply.
Want a proof of concept instead?
Where a solicitation allows it, we would rather build a working demonstration of your requirement than write about one.