Custom Applications
Software built for your business, deployed in your private cluster, operated by us.
Every business has problems that no off-the-shelf SaaS solves cleanly. The traditional answer is to bolt together five vendor products with a layer of integration code, hire someone to maintain the seams, and live with the resulting Frankenstein. The PKG answer is to build the application you actually need, deploy it in the Kubernetes environment we built for you, and run it as part of the same engagement.
This capability is rarely abstract. We have a working stack and we use it consistently:
- Python — data ingestion daemons, FastAPI services, async job orchestration
- Postgres — canonical data store, with views and materialized views as the reporting surface
- SolidJS — single-page admin UIs, fast and small
- Authentik / OIDC — identity, SSO, role-based access
- AI integration layer — retrieval, agents, conversational analysis against your private data
It's a deliberately small stack. Less to maintain, less to teach a new engineer, fewer surface areas for security drift.
What we typically build
Some patterns repeat across customers:
- Data ingestion daemons — daily or near-real-time pulls from REST APIs, databases, file drops, webhooks. With retry, observability, and incremental sync.
- Admin web UIs — operations consoles for the customer's team to monitor sync, manage users, run migrations, audit activity, export reports.
- Reporting surfaces — dynamic SQL views, registered through the admin UI, surfaced as live tables with sort/filter/paginate/CSV export.
- AI integration layers — retrieval against the canonical data, conversational analysis tools, agentic workflows, all running against models we deploy in the customer's cluster.
- Migration tooling — operators that run on a schedule, moving customer data from one system to another organization-by-organization, with rollback safety.
- Customer-facing apps — when the platform produces value the customer wants to surface to their own users (their employees, their franchisees, their customers).
How we build it
- Discovery before code — we write architecture documents and working agreements before we open an editor
- Two-week iterations — you see working software at the end of every iteration, not at the end of the engagement
- Tests as we go — not "we'll add tests later" or "QA is your team's problem"
- Heavy documentation — every component has a README. Every system has a runbook. The next engineer who touches it (yours or ours) is set up to succeed.
- Heavy use of standard tooling — Postgres, not a NoSQL flavor of the year. FastAPI, not a research framework. SolidJS, because it's good and small. Boring choices for moving parts; sharp choices where it matters.
How we run it
- We operate the cluster, the application, and the integrations under a monthly run-rate
- Enhancement work is included within an agreed envelope; large new features get scoped separately
- The application is yours; the source code is in your repository; you can take it elsewhere if you ever want to