Log in Get started

About OhioMade

Last updated: 2026-05-18

OhioMade is not a theory project. It was built from inside real business operations: gas stations, retail counters, workforce management, payroll preparation, inventory handling, vendor coordination, compliance pressure, onboarding, operational communication, and daily business survival.

Every workflow inside OhioMade was shaped by operational pressure: missing records, payroll confusion, onboarding failures, disconnected systems, billing problems, scan mismatches, missing accountability, fragmented access control, and the need for reliable mobile-first operational tools.

OhioMade is now evolving into a connected operational ecosystem: identity, workforce, payroll, infrastructure, onboarding, AI assistance, operational messaging, business access, billing, entitlements, reporting, compliance, community systems, shared branded mail, trusted sessions, and operational intelligence working together under one platform architecture.

Some OhioMade systems are live in production, while others are active platform modules still being expanded. The architecture is designed to grow without rewriting the identity, billing, access, or operational foundation.

What OhioMade really is

OhioMade is not a single app. It is a multi-realm operational platform.

The platform is structured around one central philosophy:

OhioMade behaves more like an operational environment than a collection of disconnected software products.

Identity v2 architecture

Identity v2 is the core operating layer behind OhioMade.

It controls:

Identity v2 now supports flexible login identifiers. A person may sign in using a personal email, an OhioMade identity email, or an approved username handle, while OhioMade resolves every login handle back to one permanent Identity user ID.

The login handle is not the final identity. It is only a lookup path. Internally, OhioMade resolves the submitted handle, verifies the password, applies MFA or trusted-device rules, and creates a secure cross-subdomain session for the same permanent user record.

The safe model is: personal email is a recovery, contact, and login alias; the OhioMade email is a platform identity address; username is a convenience login handle; the user ID is the permanent identity; business aliases are revocable work tools; and memberships represent business relationships.

Email does not own the account. The permanent user ID owns the account. Businesses only authorize relationships through memberships, realms, scopes, and revocable access.

MFA and trusted-device verification protect cross-subdomain sessions. Unknown devices require verification, trusted devices reduce repeat friction, and sensitive actions can require fresh verification later.

Sensitive operational areas such as Billing, VPN, Payroll, Identity Admin, and business-management actions can require stronger verification than normal browsing activity.

A single person can: own one business, manage another, operate personal services, and access multiple operational realms without mixing permissions or operational records.

This allows OhioMade apps to operate with shared identity, shared business awareness, unified operational workflows, and a cleaner separation between the human account and the business relationships around that account.

Invite, join, and approval flow

OhioMade separates joining, inviting, and approving into clean lanes. An invite does not automatically create the final operational account. An invite creates a controlled lane. Join collects the person or business request. Approval creates the actual Identity, membership, realm access, and downstream workflow records.

This allows public self-join, platform/admin invitations, and business workforce invitations to stay distinct while still feeding the same Identity foundation.

This protects the platform law: businesses do not own users; businesses authorize relationships; OhioMade owns the identity layer.

PaperTrail and document lifecycle

PaperTrail is the document source of truth inside OhioMade. It now separates employee onboarding evidence from business archive uploads.

Employee onboarding documents are tied to a person, business requirements, review status, approval state, and onboarding completion. These records support the workforce pipeline and must be approved before downstream operational readiness.

Business archive documents are different. A business may upload invoices, licenses, compliance records, vendor files, receipts, scans, or other operational documents into the active business archive without treating them as employee onboarding requirements.

This keeps compliance evidence, onboarding state, and business document storage from being mixed together.

Operational AI infrastructure

OhioMade now includes business-aware and realm-aware operational AI assistants.

Unlike generic AI chat systems, OhioMade AI operates with live operational context:

Operational assistants can already answer real business questions such as:

This architecture allows OhioMade AI to function as an operational copilot instead of a generic chatbot.

Connected realm ecosystem

OhioMade currently includes interconnected operational realms and systems:

These systems operate under one unified operational shell, shared identity layer, shared UI architecture, shared brand direction, shared mail infrastructure, and shared operational philosophy.

Infrastructure and billing

OhioMade includes commercial and infrastructure layers, not only operational tools.

VPN became the first reference implementation proving the entitlement and operational access model: supporting both person-owned and business-owned infrastructure services.

The shared mail pipeline is now part of the platform foundation. OhioMade apps should not build their own email HTML directly. Controllers should call shared mail helpers so invites, approvals, MFA codes, receipts, and future operational notices use one trusted delivery and branding path.

Remote support and operational intervention

OhioMade Remote is being built as a temporary, approval-based operational intervention layer. It is not random permanent desktop access. Remote sessions belong to Identity, a business context, and when appropriate, a Portal case.

The correct operational flow is: Identity → Business → Portal Case → Remote Session → Helper Registration → Heartbeat → Operator Connection → Audit.

The long-term helper direction is a native Windows app built with .NET and C#. The first helper version focuses on safe presence: entering a support code, registering the helper, sending heartbeat pings, polling session state, and stopping when the session ends. Screen sharing and remote control come later, after the trusted lifecycle is proven.

Mobile-first operational design

OhioMade was designed around real operational usage, especially iPhone-based workflows.

Many business operators do not sit behind desktop dashboards all day. They work from phones while handling inventory, workforce issues, onboarding, vendor communication, reporting, or infrastructure operations in real environments.

The platform includes:

Community and public systems

OhioMade also includes community-facing and public-facing systems. These systems extend the same platform thinking into public content, community pages, media, events, donations, sponsorships, and public business presence.

The Community system is part of the broader OhioMade direction: public presence, local operations, business identity, media publishing, and community coordination connected to the same operational platform philosophy.

Platform direction

OhioMade is moving toward a unified operational cloud: identity, infrastructure, workforce, payroll, onboarding, AI, communication, billing, reporting, community, and operational services functioning together under one operational architecture.

The long-term goal is simple:

OhioMade is being built as practical infrastructure for real operators, real businesses, real communities, and real operational environments.

Built in Ohio. Built for operators.

OhioMade was built by Salem Alshawabka through direct operational experience, not from abstract software theory.

The platform continues to evolve live in production through real workflows, real operational feedback, and real business pressure.

Identity v2 • Multi-business • Multi-realm • Login Handles • MFA • Trusted Devices • Operational AI • Infrastructure • Billing • Entitlements • Workforce • PaperTrail • Payroll • Community • Audit • Remote Support • Native Helper • Portal Cases