You build. JustinTime Systems Limited makes the complicated startup work go away in the background: compliance readiness, backups, maintenance, and a clear response when something breaks.
Find the support that fits your team below. Each offering explains who it is for, how we work together, and the thinking and practical examples behind the work. Links point to related articles; where a service is still taking shape, its current status is included.
How we work together: a retainer buys ongoing attention; a one-off engagement opens a defined door; a project or pilot has a scoped outcome. Infrastructure and storage costs are passed through at cost where applicable. The work is scoped with you before a fee is agreed.
Managed services
Recurring care for the systems your customers and staff rely on.
Secure Git Hosting
Forgejo behind Cloudflare Access, enforced two-factor authentication, controlled agent credentials, and encrypted off-site backups. It gives a review agent a route into the code while keeping that access inside an agreed trust boundary.
Who this is for: bootstrapped CTOs and agencies. How we work together: monthly retainer, with hosting costs passed through at cost. Behind the work: automated checks with Git hooks, reviewing your own pull request, and asking for the test.
On-Call Debugging
The response model can start with an agent that reports directly to your team. A higher-touch option adds a person to review the report, investigate, and escalate when needed. Hours, authority, and what waits until morning are agreed before the service starts.
Who this is for: solo technical founders and small engineering teams. How we work together: ongoing service; bot-facing and human-supported response levels are being shaped. Behind the work: a planned case study, idea 21, will document the approach after a suitable real incident.
MSP Cloud
Day-to-day cloud operations under one agreed service boundary, with maintenance and operational decisions visible to your team.
Who this is for: small teams without dedicated cloud operations staff. How we work together: monthly retainer. Behind the work: the planned managed-operations case study, idea 24, is not published yet.
Monitoring
Dashboards and alerts for your systems and agents, based on the monitoring stack used for our own operations. It can be bundled with cloud or maintenance work.
Who this is for: solo founders and small engineering teams. How we work together: monthly retainer, usually bundled. Behind the work: a bot handling household operations and a media bot designed around disk limits; idea 24 is planned for the managed-service details.
SaaS and Internal App Maintenance
Regular patching, hardening, and health checks for the applications customers and staff depend on.
Who this is for: founders with AI-built SaaS and agencies maintaining client applications. How we work together: monthly retainer. Behind the work: a post about a system running a month-old configuration when it is left unattended.
Cloudflare Setup
DNS, content delivery and web application firewall settings, and Zero Trust tunnels for a self-hosted stack. The servers can stay where they are while the public entry point is configured and reviewed.
Who this is for: agencies and teams running their own infrastructure. How we work together: one-off setup, with an optional care-plan retainer. Behind the work: harden-the-front-door, idea 22, is planned and not published yet.
Backups
Choose the rung that fits the system: managed BorgBase backups with restore checks; capacity on existing encrypted, append-only vaults; or BorgVault, where vaults replicate off-site. The design starts with what needs restoring and how quickly, not with a storage quota.
Who this is for: solo founders and teams whose applications hold customer or operational data. How we work together: monthly service, with storage passed through at cost. Behind the work: “Your Backup Has a Backup,” idea 20, is planned and not published yet.
Security and compliance
Find and address risks in applications and agent workflows, then make the agreed controls part of regular operations.
Two-Factor-Vaulted Agent Workflows
Agent credentials and tool access pass through a two-factor-gated vault. The workflow pauses for human approval at the boundary set for the task.
Who this is for: small teams putting agents near production systems or internal tools. How we work together: retainer or scoped implementation. Behind the work: keeping API keys away from the agent, running OpenClaw securely on NixOS, and red-teaming an agent setup.
Vulnerability Scans
Scheduled checks of software dependencies and exposed surfaces, with findings routed to the people who can decide what to fix.
Who this is for: small engineering teams without dedicated security staff. How we work together: monthly retainer. Behind the work: findings can lead to a separately scoped implementation; there is no dedicated scan case study published yet.
Copyright and Provenance Checks
Review licensing and provenance questions in AI-generated and third-party code before the team relies on it or ships it.
Who this is for: founders who have shipped code with AI tools and want to understand what is in the product. How we work together: retainer or scoped review. Behind the work: “Whose Code Is It Anyway,” idea 23, is planned and not published yet.
Agent Security Audit
A fixed-scope review of an agent stack, its permissions, credentials, and reachable tools. The result is a prioritized set of findings to discuss and address.
Who this is for: teams preparing to put an agent into regular use. How we work together: one-off, fixed scope. Behind the work: Red Team Your OpenClaw.
Security Implementations
Implement agreed fixes from an audit or scan, with the work and remaining decisions documented for the team.
Who this is for: teams that have findings but lack time or specialist capacity to implement them. How we work together: scoped from the findings. Behind the work: work is defined against each client's review findings; no general implementation case study is published yet.
Compliance Automation
Support for SOC 2 readiness and related buyer requirements using Vanta-managed workflows. The control owners and evidence remain visible to your team; a tool does not replace the decisions or responsibilities behind a control.
Who this is for: small companies facing security questionnaires or compliance requirements from buyers. How we work together: monthly service, including any applicable platform costs in the agreed scope. Behind the work: JustinTime Systems' own certification journey is in progress; certification is not yet complete.
Industrial automation
AI and automation work for plant environments, with an operator review point before a system can issue a command.
Industrial AI Integration
Connect plant signals, equipment knowledge, and specialist agents behind an operator-guided workflow. Command paths include a human review threshold defined for the equipment and task.
Who this is for: manufacturers and plant operations managers. How we work together: one-off pilot, with ongoing support scoped after the pilot. Behind the work: an introduction to the Purdue model for IT/OT security; an OT lab demonstration is still owed.
AI SCADA Replacement
Explore a greenfield, AI-native interface for monitoring and controlling industrial systems, with safety and operator authority designed into the work.
Who this is for: manufacturers replacing legacy SCADA or HMI panels. How we work together: project, followed by support if needed. Behind the work: the OT lab work is unpublished; no completed replacement case study is available yet.
Predictive Maintenance and Anomaly Detection
Use equipment signals to investigate patterns such as a stuck valve or a failing component, then test whether the signal supports a useful maintenance decision.
Who this is for: plant operations teams with costly downtime and relevant equipment data. How we work together: scoped pilot. Behind the work: the lab build is unpublished; no customer result is claimed here.
Local-First OT AI
Run models and supporting tools on NixOS and Ollama in a network designed to stay local or air-gapped. Network boundaries and operator authority are part of the design.
Who this is for: industrial teams that cannot send plant data to a cloud service. How we work together: premium retainer, scoped to the environment. Behind the work: running Ollama on NixOS and connecting a code agent to a local model.
Data and knowledge
Make the code, documentation, and operational information a team already has easier to use and verify.
Knowledge Graphs
Turn relationships in codebases and documentation into a graph a team can query, so dependencies and connections are easier to inspect.
Who this is for: engineering teams with a complex codebase or scattered documentation. How we work together: build, with ongoing maintenance scoped separately. Behind the work: using a graph database like SQLite.
Retrieval-Augmented Generation (RAG)
Build retrieval around an agreed set of internal sources, with answers that point back to material the team can check. Useful for onboarding and navigating organizational knowledge.
Who this is for: teams that spend too much time finding context across code, documents, and project history. How we work together: build, with refresh and support scoped separately. Behind the work: how I build a sourced map during onboarding.
Analytics Warehouses
Self-hosted analytics on NixOS, with data kept in infrastructure the team controls.
Who this is for: teams that need useful analytics without moving their data into an unrelated SaaS platform. How we work together: build, then ongoing support if needed. Behind the work: a secure analytics warehouse on NixOS and self-hosted Metabase.
Enablement
Give staff a working setup, then make it easier to keep that setup dependable.
The No-Fuss Stack
A flat-fee setup of Linux and OpenCode using your own model tokens, with no added subscription treadmill from the setup itself.
Who this is for: solo founders and technical self-hosters. How we work together: one-off fee. Behind the work: AI coding tools working with Nix and commands from coding agents worth keeping.
Hosted Agent Workspace
The proposed model treats the hosted environment like a safety-deposit box for agent work: usage is metered while the workspace is open, and a report shows the agent time used. A lower-cost option would let the bot report directly to your team; a higher-touch option would add human review and escalation. This billing model is still being designed, so scope, access boundaries, and rates are agreed before it is offered.
Who this is for: teams that want a managed workspace without installing it themselves. How we work together: proposed metered workspace time; pricing model in development. Behind the work: the No-Fuss Stack posts above explain the foundation; a dedicated hosted-workspace case study is not published yet.
Just-in-Time Agents
Connect agents to agreed tools and MCP servers. Staff bring their own model tokens, and onboarding includes the install and the access boundaries.
Who this is for: agencies and small product teams. How we work together: one-off setup, followed by optional ongoing support. Behind the work: the install-as-onboarding case study, idea 19, is planned and not published yet.
Self-Hosted Infrastructure
Build and maintain NixOS, K3s, n8n, Metabase, and operational bots on infrastructure your team controls.
Who this is for: manufacturers and agencies that need reproducible, self-hosted systems. How we work together: build, with ongoing maintenance scoped separately. Behind the work: a K3s deployment, an operational Telegram bot, and self-hosted analytics.
Advisory and coaching
Startup Guidance
Recommendations and reality checks on AI adoption and architecture, grounded in the constraints and evidence of the specific company.
Who this is for: founders deciding what to build or how to introduce AI. How we work together: one-off session or retainer. Behind the work: the blog's technical and product writing.
One-to-One Coaching
Regular coaching for founders who want a steady place to examine decisions and turn outcomes into useful learning. The offer's detailed terms are agreed before starting.
Who this is for: founders seeking ongoing, individual guidance. How we work together: monthly with an upfront fee, or annual with that fee waived and an early-termination clause. Behind the work: client outcomes are private unless a founder explicitly agrees to share them; no public case study is implied here.
Build
Contract MVP Building
Build a first version of a product against a scoped outcome and milestone plan, with delivery decisions tied to the runway available.
Who this is for: founders testing a product idea with limited runway. How we work together: milestone-based, with half up front. Behind the work: “Greenfield at Agent Speed,” idea 25, is planned and not published yet.
AI-Assisted Development
AI-assisted development work is listed in the catalog, but the service name and final scope are still being decided.
Who this is for: open. How we work together: open. Behind the work: name and offer details are not finalized.
On the bench
These are products in development, not current service promises.
Pull Request Review Bot
Automated review on each pull request, built to run on the hosted forge. The forge is the delivery environment; the review bot is the product.
Who this is for: small engineering teams. How we work together: in development. Behind the work: the live Git hosting and review posts linked above show related building blocks.
Nix Hosting
Reproducible deployments for teams that want a managed path to hosting Nix-built applications.
Who this is for: developers and small teams using Nix. How we work together: in development, with a freemium route under consideration. Behind the work: the Nix deployment posts linked above; the hosted product is not available yet.
Robot-Run Operations
Agents handling routine pull requests, dependency updates, and maintenance tasks with boundaries for review and approval.
Who this is for: small teams with recurring maintenance work. How we work together: in development. Behind the work: self-replicating NixOS deployment blueprints and a bot doing operational work.
Safety Layer
The developing direction is event-driven agents that detect an issue, investigate its context, and prepare a report. A person can review the report and take rescue work forward when needed. The fire-mark is a possible metaphor: mark the systems you want watched and know where to turn when something goes wrong.
Who this is for: still being defined. How we work together: in development; ongoing monitoring and metered incident response are being explored. Behind the work: no dedicated product walkthrough is published yet.
How an engagement starts
Start with the system, the people who depend on it, and the decision you need to make. From there, we can define a fixed piece of work, an ongoing service, or a pilot with a clear boundary. If a service depends on a tool, certification, or capability that is still in development, that will be made clear before scope is agreed.
Ongoing work is priced against its scope and commitment term, not just a monthly sticker. Backups, monitoring, and on-call can be scoped together so the systems we watch have a clear response path. Infrastructure and storage costs are passed through at cost. Annual terms, any waived setup fee, and early-termination conditions are stated in the agreement.
For an example of the way I map a system before proposing changes, see how I build a sourced map during onboarding.
Content on this blog was created using human and AI-assisted workflows described in my standards and workflow posts. Original ideas and editorial decisions by Justin Quaintance.