Product & platform
Product engineering
The product around the AI, or the product on its own. Typed end to end, server-rendered by default, with a design system rather than a folder of one-off components — because the cost of a product is mostly what it costs to change later.
- Next.js
- React Native
- Design systems
- SaaS & multi-tenant
- Billing
- Dashboards
What we build
- Web applications
- Server-rendered, accessible and fast on the devices your users actually have.
- Design systems
- Tokens, primitives and documented components, so the tenth screen costs less than the first.
- Multi-tenant SaaS foundations
- Tenancy, roles, invitations and audit trails designed in rather than retrofitted.
- Billing and subscriptions
- Plans, usage metering, upgrades and the dunning paths nobody remembers to build.
- Dashboards and admin tooling
- The internal screens your team runs the business on, treated as a real product.
Problems this solves
- Problem
- Every new screen takes longer than the last one did.
- Approach
- Extract a token-driven design system and typed primitives, and delete the accumulated one-off variants.
- Outcome
- The cost per screen falls instead of compounding, and the product stops drifting visually.
- Problem
- It is slow on a mid-range phone and nobody noticed.
- Approach
- Set a first-load JavaScript and Core Web Vitals budget, enforce it in continuous integration, and move work to the server.
- Outcome
- Performance is a gate that fails a pull request rather than a complaint after launch.
- Problem
- Accessibility comes up for the first time during procurement.
- Approach
- Keyboard paths, focus management and contrast checked automatically from the first sprint.
- Outcome
- The review finds nothing serious, because the issues were caught when they were cheap.
How we approach it
Discover
We read what you already have before proposing anything. Most products do not need a rewrite — they need the two decisions that made the last change expensive taken back.
Design
Interface and data model are designed together. A schema shaped by the screens is what stops the third feature from needing a migration.
Engineer
Types end to end, CI from the first commit, and something deployed in week one. Thin vertical slices, so every sprint produces something you can use rather than a layer nobody can see.
Evaluate & harden
Performance budget, accessibility review and load test before launch rather than after. We hold a page to a byte budget the same way we hold an agent to a latency one.
Launch & operate
Your team ships the next feature, not us. Handover is a design system, the decisions written down and a walkthrough — the measure is whether the second team moves as fast as the first.
What we build it with
A typed Server Action: one schema validated on both sides, tenant scoping taken from the session, and no API route in between.
"use server";
import { revalidatePath } from "next/cache";
import { z } from "zod";
const Invite = z.object({
email: z.email(),
role: z.enum(["admin", "member", "viewer"]),
});
export async function inviteTeammate(form: FormData) {
const parsed = Invite.safeParse(Object.fromEntries(form));
// The same schema the client validates against, run again on
// the server, because the client one is a convenience.
if (!parsed.success) {
return { ok: false, errors: z.treeifyError(parsed.error) };
}
const session = await requireSession();
await db.insert(invites).values({
...parsed.data,
tenantId: session.tenantId,
invitedBy: session.userId,
});
revalidatePath("/settings/team");
return { ok: true };
}Languages
- TypeScript
Frontend & mobile
- Next.js
- React
- Tailwind CSS
- TanStack Query
Databases
- PostgreSQL
- Drizzle
Cloud, DevOps & platform
- Vercel
Questions we get asked
Can you work in our existing codebase?
Yes, and often that is the sensible option. We start by reading it and telling you honestly what is worth keeping. A rewrite is occasionally right but it is rarely the cheapest route to the outcome you actually want.
Do you do design as well as engineering?
Yes — interface design, design systems and product discovery. If you have a design team we work into their system rather than around it, and if you do not, we build one that your future engineers can use without asking us.
What about mobile?
React Native or Expo where a shared codebase serves the product, and native Swift or Kotlin where the app genuinely needs the device. We are explicit about which one your case calls for, and why, before anything is built.
Who owns the code?
You do, from the first commit — your repository, your cloud accounts, your pipelines. There is nothing you have to keep renting from us for the product to keep working.
Tell us what you are trying to ship.
A first call is 30 minutes and costs nothing. Bring the problem rather than a spec — the useful part is usually working out whether this is the right shape of solution at all.
contact@algologix.coWe reply within 24 hours.