What we actually collect, and what we don't do with it.
Name, email, and message — only when you submit the contact form. Separately, every page load is logged server-side: the URL path, referrer, a coarse browser/OS string, and country (from Cloudflare's edge, not a lookup service). This is internal traffic analytics, not third-party tracking — there's no tracking pixel, no analytics cookie, no client-side script, and no data ever reaches a third party. It's used only to see which pages get visited. You can turn this off entirely from Settings.
Cloudflare D1, a database on Cloudflare's infrastructure. It's used to respond to your inquiry and isn't shared with, sold to, or accessed by any third party.
If you book a consultation via Cal.eu, that scheduling data is handled under Cal.eu's own privacy terms, not Fortior's — we only see what you'd expect a calendar invite to contain.
No GDPR, POPIA, or other formal compliance certification is claimed here — none has been independently assessed yet. This page describes actual practice, not a certified standard.
Email fortiornam@gmail.com directly — a person reads it, not a ticketing system.
Kept short on purpose.
Content on this site is informational. It describes Fortior's approach and capabilities; it isn't a contract, quote, or binding proposal.
Actual client work — scope, pricing, deliverables, timelines — is governed by an individually agreed contract per engagement, not by this page.
The site is provided as-is. It's actively maintained, but Fortior makes no uptime or availability guarantee for the marketing site or dashboard shown here.
These terms may be updated as Fortior's practice matures. Check back if it matters to you — there's no notification system for changes yet.
Not currently hiring.
Fortior is a team of one right now — Vilho Kayoko, Managing Member & CTO. There are no open roles today. If that changes, this page will say so honestly, not with placeholder job listings in the meantime.
If you'd like to be kept in mind when that changes, email fortiornam@gmail.com.
There isn't a product to document — yet.
Fortior doesn't sell a shipped, self-serve product with a fixed feature set — every engagement is a custom-built system for that client. Because of that, there's no general product documentation to publish here.
What actually happens: every engagement is documented as part of the delivery itself — the system built for you comes with real documentation specific to it, not a generic manual.
No public API — this isn't a SaaS platform.
Fortior doesn't operate a platform with a public API for you to integrate against. If your engagement involves building or exposing an API — plenty do — that's scoped, built, and documented specifically for that project, not offered as a generic Fortior product.
Not a product roadmap — Fortior doesn't have one. This is how we think about the work.
An engineering and technology consultancy. We build, secure, and scale the systems a business runs on — a custom system designed for how you actually work, not a shared product with a login for every customer.
Not a SaaS platform with a subscription, a roadmap of upcoming modules, or a multi-tenant product you sign up for. If that ever changes, this page will say so plainly — it won't happen quietly.
Duplicate systems, manual reporting, disconnected client data, and processes held together by spreadsheets and memory. See the homepage for the fuller before/after picture — it's the same list, not a different pitch for this page.
Scope, design, build, verify, operate — documented at each stage, reviewed with your team before code ships. See Services for the full breakdown.
The dashboard and AI assistant mockups on the homepage are real interface concepts, clearly labeled — not evidence of a shipped product. Every other capability (CRM-style systems, financial reporting, HR tooling) is built specifically per engagement, not held in reserve for a future release.
One real preference. No account, so no fake account settings.
Genuinely applies site-wide and remembers your choice — this isn't decorative.
Every animation on this site already respects your OS-level reduced-motion setting. This overrides it in either direction, in case your OS setting doesn't match what you want right now.
No cookies, no tracking pixel, no third-party analytics service, no client-side script watching you. Page paths are logged server-side for internal traffic counts — see Privacy for exactly what that covers and what's collected via the contact form.
There's no visitor account system on this site. If you're looking for the internal dashboard, that's a separate, authenticated area — not something this page controls.
Clears everything stored above — theme, motion, and the tracking opt-out — back to their defaults.
Fortior builds, secures, and scales the systems enterprise and government organizations run on. Every claim on this site is one you can verify — and the person on your consult call is the person who builds your system, not an account manager who hands you off.
Software, automation, and infrastructure designed for the operation you actually run.
Ongoing engineering support so what's built keeps running under real load.
Data, analytics, and advisory that turn operational history into decisions.
This is the shift an engagement is built to produce, not a claim about a packaged product — every item on the right maps to a real service below.
Not shipped products or line items on a price list — custom systems, built per engagement. Click a category to see what that means in practice.
Illustrative — describes the kind of system built for that engagement type, not a screenshot of an existing Fortior product.
We define the operational problem in writing before any build begins — what's broken, what "solved" looks like, and how we'll know.
Architecture and interfaces reviewed with your team before a line of production code is written.
Iterative delivery with visible progress — no black-box development.
Testing and handover documentation you can audit, not a demo you have to trust.
Ongoing support with a defined SLA, not an open-ended promise.
A concept, built to show the shape of a Fortior-built system — not a screenshot of anything live.
Concept interface — sample data for illustration only. Not a screenshot of a live Fortior product or real client records.
| Area | Status |
|---|---|
| Dashboard interface | Concept Preview |
| AI query assistant | Concept Preview |
| Client & pipeline systems (CRM-style) | Built per engagement |
| Financial reporting & reconciliation | Built per engagement |
| HR & workforce tooling | Built per engagement |
| Inventory & operations systems | Built per engagement |
Fortior is a consultancy, not a product company — there's no roadmap to ship these as a shared platform. "Built per engagement" means exactly that: designed for the client who needs it, not a module waiting on a release date.
A separate, fully interactive build of the concept above — real command palette, real notifications, a working task board, across nine sample views. It's marked as a concept throughout, including inside the app itself, because it's illustrative, not a screenshot of a shipped Fortior product.
How these capabilities map to common problems in your industry — not client case studies. There isn't a published engagement in every category yet; this is the approach, not a track record.
No uptime percentage or response-time figure shown — Fortior doesn't run monitoring infrastructure to measure those yet, so we won't publish a number we made up.
Every consult is with someone who will actually work on your systems — not an account manager.
Book a consultFortior exists because too much enterprise technology work is sold on confidence rather than evidence. We'd rather show our working.
Fortior is in an active build phase. Where we don't yet have verifiable proof — a client-approved case study, a named credential — we say so plainly rather than dress up a placeholder. That's the standard we're holding the whole site to, not just this page.
Three pillars, held together — because engineering that isn't operated fails, and operations without data don't improve.
Purpose-built systems for the operation you actually run, not a generic template bent into shape.
Removing manual, error-prone steps from processes that shouldn't need a human in the loop.
Making existing tools talk to each other instead of living as disconnected silos.
Secure, maintainable web applications built to a documented spec.
Structured rollout of enterprise resource planning systems, scoped to what the business needs.
Cloud and on-premise systems kept running to a defined standard.
Responsive support with clear escalation paths, not a ticket queue that disappears.
Hardening and monitoring built into the operating model, not bolted on after an incident.
Four true things, not eight aspirational ones. This updates as the practice matures — nothing here is a certification claim.
Hosted on Cloudflare — real DDoS and edge protection, not a badge.
Internal systems require credentials, not open access — single-factor by design choice.
Authenticated internal access is recorded, not silent.
Honeypot filtering and server-side validation on public-facing forms.
One authorized operator on internal systems — no shared or orphaned credentials.
Query and booking details are used to respond to you — nothing more.
Turning operational history into decisions leadership can actually act on.
Independent counsel on architecture and vendor decisions before they're locked in.
Marketing and digital presence built with the same rigor as the systems behind it.
Fortior is in an active market-entry phase. Rather than publish placeholder case studies, we're documenting the standard we'll hold every future engagement to.
Every engagement listed here in future will be real, named (where the client permits), and described with metrics we can defend — not invented figures dressed up to look like proof. If you're an early client, ask us about being our first published engagement.
Scope, timeline, and what changed operationally — written the way we'd want a peer engineer to read it.
Client-approved results, quantified only where we can stand behind the number.
Tell us the problem. We'll tell you honestly whether we're the right fit before anything else happens.
Answers drawn only from what's actually published on this site — services, industry pages, and the engineering docs. No pricing, no delivery dates, no legal advice: those need a real conversation.
This answers from published site content only — it won't quote a price, promise a date, or give legal advice. For any of those, book a consult.
Not a marketplace, and not a customer count. This is the engineering depth Fortior brings into a client engagement — the platforms, databases, and infrastructure we integrate, not products we resell.
This site, its admin panel, and Fortior's client-facing infrastructure run on Cloudflare Pages and Workers — real usage, not a listed partner badge.
Source control and the deploy pipeline for every Fortior-built system — a push to the tracked branch is what ships a change.
Scheduling and booking infrastructure, wired directly into the Contact page — the same booking flow a client engagement would get.
SQLite at the edge — what stores contact-form submissions and admin records for this site today, and a real option for client systems with similar scale.
Engineering depth here comes from client engagements, not a hosted product of Fortior's — scoped and selected per the system being built, not a fixed default.
Custom-built per engagement, as described on the homepage — not a pre-built product with an install count.
Connected during a build when a client's engagement calls for it — see Services for how that's scoped.
Every entry above is a capability Fortior has engineering depth in, not a live customer connection. There's no marketplace, no install count, and no "1,200+ businesses use this" claim — that's SaaS-vendor theater this site doesn't borrow.
Real write-ups, not aggregated SEO filler. Two pieces exist today — more will be added as there's something genuine to say.
The reasoning behind Fortior's three-pillar model, and why engineering that isn't operated tends to fail quietly.
Technical noteA generic write-up of the access-control pattern used on a recent client admin build — described in the abstract, not exposing that client's implementation.
This is an honest two-article start, not a grid padded out with placeholder cards. More gets added as there's a real piece worth publishing.
Most software projects are scoped, built, handed over, and then abandoned by the team that understood them best. What breaks six months later gets fixed by whoever's cheapest and available — usually not the people who built it, and rarely with the original context intact.
Software, automation, and infrastructure designed for the operation a client actually runs — not a template bent into shape. This part looks like most consultancies' pitch. It's the next two pillars that don't.
The same team that built the system stays on to run it — patching, monitoring, and handling the small operational issues that a handed-off codebase usually surfaces slowly, and expensively, without anyone tracking them.
Once a system is built and stable, its operational history becomes usable data — the basis for reporting, forecasting, and decisions that weren't possible when the same process was running on spreadsheets.
Splitting build from operate is where the handoff loss happens. Keeping both under one accountable team is the actual mechanism, not the marketing description, behind "proof over polish."
Generic write-up — describes the pattern, not a specific client's data or credentials.
A small internal admin panel — a handful of authorized users, no need for a full identity provider — still needs real access control and a record of who did what. Skipping this because "it's just an internal tool" is how quiet incidents happen.
Basic Auth, enforced at the edge (a middleware function in front of the admin routes), gated behind credentials that aren't shared or reused elsewhere. Single-factor by design for a single-operator panel — the honest tradeoff, not a hidden one.
Every authenticated action against the admin API — read or write — gets a log entry: who, what, and when. The log itself is append-only and reviewable, so "who touched this record" has a real answer instead of a guess.
This pattern shows up across small internal tools generally, not just one build: gate the routes, log the access, keep the log separate from the data it's watching. It's a reasonable default before reaching for a heavier identity system the panel doesn't need yet.
Not client-facing product docs — Fortior doesn't ship a product to document (see Documentation). This is the engineering record for fortior-site itself: real architecture, a real changelog, kept current as things actually ship.
System overview, D1 schema, auth flow, booking flow, deployment pipeline, and security considerations — as built, not as idealized.
StatusWhat's shipped, what's in progress, and what's planned — updated as things actually ship, not padded to look more active than it is.
WritingTechnical notes and write-ups — the same honest, engineering-record voice as this section.
This is a two-page start — Architecture and Roadmap — not a nav padded out with placeholder sections. A Getting Started, Features, or FAQ page gets added if there's ever real content for one.
fortior-site as it's actually deployed today — nothing here is aspirational.
Cloudflare Pages serves the static site (this file, index.html, and the admin panel's admin/index.html) plus a set of Cloudflare Pages Functions under /functions — small edge JS handlers for form submission, stats, the admin API, and Ask Fortior. Data lives in a single Cloudflare D1 database (SQLite at the edge) bound as DB, plus a Workers AI binding (AI) for Ask Fortior's inference calls. There is no separate application server, no KV namespace, and no queue — four moving pieces, not a distributed system pretending to be simple.
The Ask Fortior panel (functions/api/ask.js) answers visitor questions using Workers AI (@cf/meta/llama-3.3-70b-instruct-fp8-fast), grounded in a fixed context assembled from this site's actual pages — services, industry pages, and these docs — via scripts/generate-ask-context.js into functions/lib/site-context.json. The system prompt instructs the model to answer only from that context, and to refuse and redirect to a consult on pricing, delivery timelines, legal questions, and binding commitments. It's rate-limited per IP in D1 (ask_rate_limit, migration 0003) rather than KV, for the same reason noted above — this project has no KV namespace. Workers AI is billed per request beyond Cloudflare's daily free Neuron allowance; it isn't free at scale.
Five tables exist in the production database (fortior-admin-data), confirmed directly against it — not written from memory:
queries — id, name, email, message, created_at, source_ip, user_agent. Written by the public contact form (/api/submit).
pageviews — id, path, created_at, referrer, user_agent, country. Written server-side by the root _middleware.js on real HTML page loads only; no client-side script, no cookies. Skipped entirely when the request URL carries ?dnt=1, which Settings sets via a localStorage flag mirrored into the URL — the only way a client-side preference can reach a server-side check without a cookie.
bookings — id, summary, attendee, starts_at, created_at. Not auto-populated — see Booking flow below.
contacts — id, name, email, phone, company, type, notes, created_at. Admin-managed CRM-style records.
audit_log — id, ts, user, action, module, device, ip, outcome. Written on every request to /admin/*, success or failure.
Two of the five tables (queries, bookings) were created directly against D1 and aren't tracked as migrations in this repo — only contacts/audit_log (migration 0001) and the pageviews instrumentation columns (migration 0002) are. That gap is a real known gap, not hidden here.
The admin panel (/admin/*) is gated by HTTP Basic Auth, enforced in functions/admin/_middleware.js at the edge — before any admin route or API handler runs. Credentials are two Cloudflare Pages environment variables (BASIC_USERNAME, BASIC_PASSWORD), never committed to the repo. This is single-factor by design: a single-operator panel, not a multi-user system, so there's no TOTP or second factor layered on top of it today. Every request under /admin — successful, wrong-credentials, or no-credentials — gets an audit_log row (user, action, module, device, IP, outcome), and authenticated responses carry X-Robots-Tag: noindex, X-Frame-Options: DENY, and related hardening headers.
Scheduling runs on Cal.eu (Cal.com's EU-hosted product, at cal.eu/fortior), embedded directly on the Contact page via Cal.eu's own embed script. There's no server-side integration or webhook wired up — Cal.eu owns the booking UI, confirmation emails, rescheduling, and cancellation entirely on its own infrastructure. The bookings table in D1 is a manually-maintained log, updated from Cal.eu's confirmation emails, not a live sync — the admin dashboard says so plainly rather than implying it's automated.
Cloudflare Pages is Git-connected to MrTalisman21/fortior-site on GitHub. Every push to master triggers an automatic build and deploy — no manual upload, no separate CI file, no deploy token stored anywhere in this repo. It's a genuinely simple setup: commit, push, Cloudflare builds and serves it.
Practices actually followed in this project, not a general best-practices list: secrets (BASIC_USERNAME/BASIC_PASSWORD) live only as Cloudflare Pages environment variables and in a local .dev.vars file that's .gitignore'd and has never been committed. Deploys are authenticated through Cloudflare's Git integration (OAuth-based), not a long-lived API token checked into config. The contact form is honeypot-protected against basic bot spam. Analytics logging is cookie-free and server-side only, so there's no client-side tracking script to compromise. None of this is a claim of a hardened security program — it's an accurate list of what's actually in place on a small consultancy site.
Kept current as things actually ship. A stale roadmap is worse than no roadmap.
Admin portal — contacts, audit log, real-data analytics, CSV export, all served from Cloudflare D1.
Contact management — public contact form writing into D1, honeypot-protected, with a CRM-style contacts view in the admin panel.
Analytics dashboard — server-side, cookie-free pageview logging; total views, daily trend, and top pages, from the real pageviews table.
Industry solution pages — eight sector-specific pages under Solutions.
Cal.eu booking integration — live scheduling embed on the Contact page, plus a manually-maintained bookings log in the admin panel.
Docs portal — this section: architecture reference and this roadmap, tying together what already exists.
Ask Fortior — a grounded Q&A panel at /ask, backed by Workers AI and restricted to answering from real published site content. See Architecture for how the grounding and guardrails work.
Referrer, device, and country breakdowns in the analytics dashboard — the D1 columns already exist (migration 0002) and are being populated now; the dashboard sections ship once there's enough real data to chart honestly.
Nothing else is committed to a specific date. This list stays short on purpose — see Approach for why Fortior doesn't publish a padded product roadmap.
How Fortior's Build, Operate, Grow model applies per industry — not client case studies. There isn't a published engagement in every category yet; this is the approach, not a track record.
Inventory, service records, booking, and lead follow-up in one place.
Multi-site project tracking, resource scheduling, subcontractor coordination.
Reservations, unified guest data, and shift-pattern-aware staff scheduling.
Inventory and POS integration, unified customer data, multi-location reporting.
Fleet and shipment tracking, route automation, real-time reporting.
Patient scheduling and records built around how the practice actually runs.
Enrollment records, guardian communication, administrator-first reporting.
Client and matter tracking, time and billing, document management.
Dealerships and service operations run on inventory, service records, and booking — usually across tools that don't talk to each other.
Vehicle and parts inventory that matches reality, service history attached to the right vehicle and customer, and a booking flow that doesn't drop leads between the website, the phone, and the service bay.
Build: unified inventory and service-record systems, plus scheduling that reflects real bay capacity. Operate: the same team keeps the booking and inventory systems running through busy periods, not just at launch. Grow: service and sales data becomes reporting on what's actually moving, not a manual monthly tally.
Discovery starts with how vehicles, parts, and bookings currently move through your existing tools — spreadsheets, a legacy DMS, or a mix. The build phase targets the biggest single point of duplication first, not a full-system rebuild on day one.
Multiple sites, shared equipment, and subcontractors who need the same information at the same time — usually held together by phone calls and spreadsheets.
Project tracking that works across multiple active sites at once, equipment and resource scheduling that avoids double-booking, and subcontractor coordination that doesn't rely on someone remembering to make a phone call.
Build: a project-tracking and scheduling system built around how your sites actually report status. Operate: the system stays supported through a live project, not just at handover. Grow: site data becomes real progress reporting for the office, not a reconstructed summary after the fact.
Discovery maps how status currently gets from a site to the office — and where it gets lost. The first build phase usually targets whichever site or resource-scheduling gap is causing the most rework.
Reservations, guest data, and staff scheduling — three systems that often live in three different places.
A reservation and booking system that doesn't double-book, guest data held in one place instead of five, and staff scheduling that matches real shift patterns rather than a generic roster template.
Build: booking and guest-data systems designed around your actual property or venue. Operate: support through peak season, when booking systems get tested hardest. Grow: occupancy and guest data turned into decisions on staffing and pricing, not a spreadsheet nobody has time to update.
Discovery covers how bookings and guest records currently flow — often across a booking platform, a spreadsheet, and front-desk memory. The build phase consolidates that into one accurate source before anything more ambitious is scoped.
Inventory, point-of-sale, and customer data across one location or many — usually not reconciled with each other in real time.
Inventory that stays accurate against point-of-sale activity, customer data unified across whatever channels you sell through, and reporting that actually works across multiple locations instead of one spreadsheet per branch.
Build: inventory and POS integration built for your actual store layout and channel mix. Operate: kept running through peak trading periods, not just launch week. Grow: sales and stock data turned into real decisions on what to reorder and when, not a guess.
Discovery starts with where stock counts and sales data currently disagree with each other. The first build phase closes that specific gap before expanding to reporting or multi-location rollout.
Fleet, shipments, and routes — where the cost of a delay usually shows up as a phone call, not a dashboard alert.
Fleet and shipment tracking that reflects reality, route and scheduling automation instead of a dispatcher's memory, and reporting that's live rather than reconstructed at the end of the week.
Build: tracking and scheduling systems built around your actual fleet and delivery patterns. Operate: kept running as routes and volumes change, not frozen at launch configuration. Grow: delivery and fleet data becomes a real basis for route planning, not a lagging weekly report.
Discovery maps how a shipment is tracked today from dispatch to delivery. The first build phase usually targets the point where visibility currently drops — often the handoff between dispatch and the driver.
Patient scheduling and records, built around how a practice actually runs — with no compliance certification claimed that hasn't been earned.
Patient scheduling and record systems that match how a specific practice operates, not a generic template — and an engineering partner who states plainly what compliance posture is and isn't in place, rather than a badge wall.
Build: scheduling and record systems scoped to your practice's actual patient flow. Operate: ongoing support with the access-control discipline described on Services. Grow: patient and scheduling data turned into operational reporting for the practice, not a vendor dashboard nobody asked for.
Discovery includes an explicit conversation about what regulatory or compliance requirements actually apply to your practice, before any system design starts — so the build is scoped against a real requirement, not an assumed one.
Enrollment records, guardian communication, and reporting built for administrators — not IT staff.
Student and enrollment record systems that a school administrator can actually use, parent and guardian communication that doesn't rely on a group chat, and reporting built for the people who run the institution day to day.
Build: enrollment and communication systems designed around your school's actual admin workflow. Operate: support through enrollment periods and term changes, when these systems get used hardest. Grow: enrollment and attendance data turned into reporting administrators can act on.
Discovery starts with how enrollment and guardian communication currently happen — often a mix of paper forms, spreadsheets, and messaging apps. The build phase targets consolidating that into one system administrators can run without IT support.
Client and matter tracking, time and billing, and document management — the operational backbone of a firm, not its differentiator, but usually the thing slowing it down.
Client and matter tracking that stays current without manual re-entry, time and billing systems that hold up under audit, and document and knowledge management that doesn't scatter files across inboxes and local drives.
Build: tracking, billing, and document systems built around how your firm actually bills and delivers work. Operate: ongoing support with the same access-logging discipline used on Fortior's own internal tools. Grow: utilization and billing data turned into decisions on capacity and pricing.
Discovery maps how time, matters, and documents currently move through the firm. The first build phase usually targets whichever manual re-entry step is costing the most billable time.