The portfolio spans live business systems, focused operational applications, active product development, public AI systems, and research infrastructure.
A pilot is not a released product.
A private application is not automatically a public platform.
A small application does not need a large architecture to be engineered seriously.
LIVE BUSINESS SYSTEMS
SAALIK SYSTEMS
LIVE / PRODUCTION
A commercial system connected to an operating business workflow.
Saalik Systems connects public service understanding, structured inquiry, durable records, notification, and human review.
Read the full case study
Saalik Systems needed more than a page describing services.
It needed a digital front door that could explain the company, help a potential customer determine whether there is a fit, collect useful project context, preserve the inquiry, and move it into the operating workflow.
The visible website sits on top of a larger flow:
Visitor → Capability & Service Context → Structured Inquiry → Durable Record → Notification → Human Review & Response
IRONCLAD PROPERTY SERVICES
LIVE / PRODUCTION
A customer-facing system built around a real operating service business.
Ironclad Property Services needed a public system that could explain the service clearly, move customers toward the right action, and support the business's actual operating model.
The implementation was shaped around the customer path and the information the business needs in order to act.
IKT PROPERTY SERVICES
LIVE / PRODUCTION
A mobile-first public information and quote-intake system for IKT Property Services.
The system presents services and pricing context, collects the information needed for a quote request, preserves the lead, and leaves customer approval with the business owner.
IKT Property Services is presented as its own business and its own implementation.
The public system supports a direct customer path from service discovery into structured quote intake.
The operating flow is:
Customer Interest → Services & Pricing Context → Quote Request → Structured Lead Record → Owner Review
The intake captures useful job and property information before owner review.
A quote submission does not automatically create customer acceptance, scheduling, payment authorization, or a service agreement.
LIVE OPERATIONAL APPLICATIONS
CONTACTFLOW
CONTACTFLOW
LIVE / TESTED
A mobile-first contact capture and recovery system built for real-world networking.
ContactFlow preserves the person, the conversation, and the next move before the context disappears.
Read the full case study
CONTACTFLOW
ContactFlow was built for a narrow operational problem:
after meeting somebody, capture enough information to remember who they are, what was discussed, what matters, and what should happen next.
The operating loop is intentionally small:
Capture → Preserve → Triage → Follow Up
A contact can include a name, organization, role, contact information, conversation context, next action, priority, and capture time.
Useful partial records are allowed. Structurally empty records are rejected.
Preserve first. Transmit second.
ContactFlow does not assume that pressing Save means the contact successfully crossed the network.
Before transmission, the record receives a stable identity and is preserved locally.
If delivery cannot be confirmed, the interface does not claim success.
The record remains available for review and retry.
Multiple unsent contacts can coexist independently.
Small architecture. Deliberate boundaries.
ContactFlow uses a deliberately compact architecture:
a lightweight frontend + protected backend + structured delivery + local recovery
There is no public need to expose the vendor stack behind those layers.
The important architectural point is that the system includes the controls its use case requires without introducing infrastructure that does not solve the problem.
Authentication and validation live on the authoritative side.
The application uses server-enforced authentication and protected sessions appropriate to its private operational scope.
The backend independently validates submitted records and enforces the request boundary even if somebody bypasses the intended interface.
“Contact saved” actually means something.
The interface does not report success merely because the user tapped Save or a request was attempted.
Success is shown only after delivery acceptance can be confirmed.
If acceptance cannot be established, the record remains in the unsent queue.
The interface does not claim a stronger state than the system can prove.
Retries preserve identity.
Each contact receives a stable record identity before transmission.
That identity survives interruption and retry.
The system can distinguish an unchanged retry from an edited retry instead of treating every retry as a brand-new contact.
A public path out of the conversation.
ContactFlow keeps the public QR handoff available during an in-person interaction, giving the other person an immediate path to continue online.
Tested.
ContactFlow reached:
17 / 17 AUTOMATED TESTS PASSING
The number refers to the defined automated suite.
The verified behavior covers areas including meaningful partial records, empty-record rejection, field validation, retry identity, session behavior, protected routing, request enforcement, provider-failure behavior, and unchanged retries.
Recovery checks also covered queued failures, multiple unsent records, correct retry restoration, stable identity, draft restoration, and degraded local-recovery behavior.
This is evidence for the tested contracts.
It is not shorthand for “100% tested,” defect-free operation, or proof at arbitrary scale.
ACTIVE PRODUCT DEVELOPMENT
WHEN THE PROBLEM IS BIGGER, THE ARCHITECTURE CAN BE TOO.
ContactFlow demonstrates restraint.
Radar and ECS demonstrate what happens when the underlying problem legitimately requires more state, integration, and operational depth.
RADAR
RADAR
LOCAL PILOT / ACTIVE DEVELOPMENT
Market observation and opportunity intelligence infrastructure.
Radar observes markets, preserves evidence about what it sees, and makes that evidence usable by downstream systems.
Read the full case study
RADAR
Radar's responsibility is deliberately narrower than deciding what a customer should do.
It focuses on questions such as:
What is observable?
Where did the information come from?
How fresh is it?
How much of the market was actually covered?
What evidence supports the result?
Can a downstream system use the evidence without inheriting hidden assumptions about its user?
That creates a clean responsibility boundary:
MARKET EVIDENCE → DOWNSTREAM DECISION SYSTEM
Radar knows the market. The consuming system knows the buyer.
Radar is implemented and in local-pilot development.
It is not being represented as a publicly released product.
ECS
ECS
ACTIVE PRODUCT DEVELOPMENT / PILOT
A stateful shopping system built around what happens before, during, and after the store.
Read the full case study
ECS
ECS began with a household shopping problem.
The real process is larger than finding a coupon.
There are needs, stores, prices, offers, availability, substitutions, changing in-store conditions, checkout truth, and the receipt that says what actually happened.
ECS organizes that into:
NEED → FIND SAVINGS → PLAN → SHOP → RECONCILE → TRACK
The system includes work around household needs, store selection, market opportunities, coupons and rebates, trip planning, in-store state, substitutions, unresolved needs, receipt reconciliation, realized savings, persistent purchasing state, and degraded operation when dependencies are unavailable.
ECS can consume Radar evidence while preserving a clean boundary:
Radar supplies market evidence.
ECS decides what that evidence means for the household and the trip.
PUBLIC AI SYSTEMS
GOVERNED CONTEXT ARCHITECTURE — LIVE AGENTS
LIVE / PUBLIC
One AI does not need to own the entire job.
PLAN → BUILD → AUDIT
Read the full case study
Saalik Systems implemented three public AI systems for Governed Context Architecture.
Each owns a different role.
GCA PLANNER — PLAN
Clarifies the problem, organizes requirements, exposes unresolved decisions, and helps determine what needs to happen next.
Challenges work for gaps, contradictions, unsupported claims, risks, and unresolved issues without acquiring authority to approve or redesign the work.
Saalik Systems is the implementation company that built its current public digital systems.
Those systems include the GCA website, publication infrastructure, public AI systems, and access to three published white papers.
One of those papers, Authority Beyond Expertise, develops the distinction among capability, expertise, execution, and authority in AI-assisted software construction.
WHAT THE PORTFOLIO ACTUALLY SHOWS
BIG SYSTEMS ARE NOT BETTER SYSTEMS.
A service-business operating system.
A focused mobile contact application.
A market-intelligence backend.
A stateful consumer product.
Bounded AI systems.
A research platform.
Those are materially different problems.
That difference is part of the evidence.
Saalik Systems is not organized around forcing every problem into the same technical stack.
The objective is to understand what the work requires and build accordingly.
BUILD ONLY AS MUCH SYSTEM AS THE PROBLEM REQUIRES—BUT BUILD ENOUGH SYSTEM FOR THE PROBLEM TO BE TRUSTWORTHY.
STATUS IS PART OF THE CLAIM.
LIVE / PRODUCTION means the system is operating in its intended real business environment. It does not, by itself, claim enterprise scale or independent certification.
LIVE / TESTED means the application is operating in its intended bounded use and has passed its applicable verification.
LOCAL PILOT / ACTIVE DEVELOPMENT means substantive implementation exists and bounded real-world validation is underway without a broader public release claim.
ACTIVE PRODUCT DEVELOPMENT / PILOT means a product is being built and validated but is not being represented as a released consumer offering.
LIVE / PUBLIC means the public can access the system now.
Those distinctions are intentional.
We would rather label the work correctly than make everything sound finished.
HAVE A PROBLEM THAT DOESN'T FIT A NEAT SOFTWARE CATEGORY?
You do not need to decide whether you need an application, an AI assistant, automation, a workflow, an integration, an internal tool, or something else.
Start with the problem.
Tell us what happens now, what is difficult, and what you need to happen instead.
