# Fajarix — Full Site Content > AI-native software development agency headquartered in San Francisco. > We build production web apps, mobile apps, generative AI systems, and full > product teams — shipped by senior engineers in weeks, not quarters. ## About Fajarix Fajarix is an AI-native software development agency founded in 2024. Headquartered in San Francisco with a distributed senior engineering team, we deliver software for clients worldwide — from US-based startups to European enterprises and Australian e-commerce brands. Our positioning is simple: world-class engineering quality, senior engineers on every build, transparent fixed-scope pricing, AI-native architecture, and a 24-hour response promise. ## Service Pillars ### AI & Automation We build production AI systems for businesses worldwide: - **Generative AI applications** — chatbots, content generation, AI assistants - **Autonomous AI agents** — agents that take actions, not just respond - **LLM integration** — OpenAI, Anthropic Claude, Google Gemini connected to your existing software - **RAG (Retrieval-Augmented Generation)** — connect LLMs to your private data - **Workflow automation** — n8n, Zapier, custom pipelines that save 20+ hours/week - **Custom AI pipelines** — domain-specific AI for healthcare, fintech, logistics, etc. Typical projects start from $3,000 for simple chatbots and range to $25,000+ for full enterprise AI pipelines. Production-ready chatbots take 2–4 weeks; complex autonomous agents take 6–10 weeks. ### Web Development Custom web application development for SaaS platforms, dashboards, marketplaces, and enterprise software. We work with React, Next.js, TypeScript, Node.js, PostgreSQL, Redis, and cloud platforms (AWS, GCP, Vercel). We also handle legacy modernization — rebuilding PHP/Java apps in modern stacks, migrating to Next.js or React, and optimizing performance to 95+ Lighthouse scores. MVPs take 4–6 weeks; full SaaS platforms 10–20 weeks. ### Mobile App Development iOS, Android, and cross-platform mobile apps. We use Flutter for most projects (single codebase, near-native performance) and React Native when projects need deeper JavaScript ecosystem integration. We handle full App Store and Google Play submission including metadata optimization, screenshots, and review responses. Cross-platform MVPs ship in 8–12 weeks. Feature-rich consumer apps with backends ship in 14–20 weeks. ### Staff Augmentation Pre-vetted senior engineers embedded directly into your team. Our engineers work your hours, use your tools, attend your standups, and report to your team leads — operating like in-house hires — without the hiring overhead. We can present candidates within 24 hours and onboard within 48 hours. Roles include full-stack engineers, mobile developers, backend specialists (Python, Django, FastAPI), QA engineers, DevOps/Cloud engineers, and UI/UX designers. ### Product Engineering End-to-end product development. We take products from idea to MVP in 6–8 weeks, then scale them. The engagement covers product strategy, UX wireframes, high-fidelity design, full-stack development, QA, CI/CD, cloud deployment, and post-launch iteration. MVPs typically cost $8,000–$35,000 depending on complexity. Most clients continue with us after launch on monthly product iteration retainers. ### UI/UX Design Design systems, user research, Figma prototypes, and pixel-perfect interfaces. A typical engagement covers UX research, lo-fi wireframes, high-fidelity designs, interactive prototypes, design systems with component libraries, and complete developer handoff. Design projects start at $2,500 for simple apps and reach $12,000+ for multi-platform products with full design systems. ## Industry Solutions ### FinTech Secure, compliant FinTech software: - KYC/AML automation - Payment gateway integration (Stripe, Adyen, Checkout.com, Plaid) - Banking dashboards and lending platforms - Crypto apps with regulatory compliance - PCI DSS compliance from day one ### Healthcare HIPAA-compliant healthcare software: - Telemedicine apps with WebRTC video consultations - Patient portals and appointment scheduling - EHR integration via HL7 FHIR - Wearables integration (Apple Health, Fitbit, Garmin) - AI symptom checkers and clinical decision support ### E-Commerce High-performance e-commerce platforms: - Custom storefronts on Shopify, Magento, WooCommerce - Headless commerce with Next.js + Shopify Storefront API - Two-sided marketplaces with payment escrow - AI-powered product recommendations - International commerce (multi-currency, VAT, localization) ### EdTech Modern learning platforms: - LMS systems (build vs. Moodle/Canvas extension) - Live tutoring with WebRTC - AI tutors with adaptive learning algorithms - Certification and assessment systems - COPPA, FERPA, GDPR compliance ### Logistics Supply chain and fleet software: - Fleet management with real-time tracking - Route optimization (TSP-class algorithms) - Warehouse management systems - Last-mile delivery platforms with driver mobile apps - Logistics API integrations (UPS, FedEx, DHL) ### Real Estate (PropTech) Modern real estate technology: - Property listing platforms at scale - Agent CRMs with lead automation - Virtual tour apps (360°, AR, VR) - Rental management with payment automation - AI property valuation models - MLS integration ### Startups Investor-ready MVPs from $8K in 6–8 weeks. We act as a technical co-founder service for early-stage teams: rapid prototyping, SaaS boilerplates, demo prep, fundraising-ready architecture. We continue post-fundraise as scaling partners. ## How We Work - **Engagement models**: fixed-price projects, monthly retainers, staff augmentation - **Cadence**: weekly demos, daily standups, async-first communication - **Tools**: GitHub, Linear, Notion, Slack — we use yours, not ours - **IP protection**: full IP transfer in contract, all code yours from day one - **Payment**: 50% upfront for fixed-price; net-30 monthly for retainers - **Geographic coverage**: USA, UK, EU, Australia, Canada, MENA — any timezone ## Why Choose Fajarix - **Senior engineers only** — no junior bait-and-switch - **Transparent pricing** — fixed-price quotes, no hourly bait - **AI-native architecture** — every project gets AI-augmented code review and ops - **Speed as proof point** — first release in 2–6 weeks, not quarters - **No agency middlemen** — you talk directly to the engineers building your product - **24-hour response promise** — across business hours globally ## Contact - Project enquiries: https://fajarix.com/contact - Email via the contact form on the site - LinkedIn: https://www.linkedin.com/company/fajarix - Free consultation, response within 24 hours --- ## Recent Blog Posts (Top 10) The following section contains the 10 most recent blog posts in full markdown form. For older posts or per-post mirrors, fetch `https://fajarix.com/blogs//llms.txt`. --- ## Getting to 95+ Lighthouse in a Real Next.js App Source: https://fajarix.com/blogs/getting-to-95-lighthouse-real-nextjs-app Category: Web Dev Published: 2026-07-07 > Anyone can score 100 on a hello-world page. Hitting 95+ on a real Next.js app — with analytics, custom fonts, hero images, and a marketing team — takes a specific set of techniques. Here is the exact checklist we run, with code. Scoring 100 on a hello-world page proves nothing. The interesting problem is scoring 95+ on a *real* application — one with a tracking pixel the marketing team refuses to remove, a custom font the brand guide demands, a hero image the designer keeps swapping, and eleven third-party scripts of varying legitimacy. We have taken multiple production Next.js apps from the low 60s into the mid-to-high 90s, and the work is never one magic fix. It is the same eight or nine techniques, applied in the same order. This is that checklist, with the actual code. ## Step 0: Measure the Right Thing Before touching code, two ground rules. First, **lab scores and field data are different animals.** Lighthouse in your DevTools is a lab test on your hardware; Google's Core Web Vitals assessment (and your search ranking) come from field data collected from real Chrome users over 28 days. We optimise against lab scores for fast iteration but treat field data — via the Vercel Speed Insights dashboard or the Chrome UX Report — as the source of truth. Second, **always test production builds.** `next dev` is unoptimised by design; auditing it wastes everyone's afternoon. Run `next build && next start`, test in an incognito window (extensions pollute traces), and run Lighthouse 3-5 times taking the median, because single runs vary by several points on any machine. ## 1. Let Server Components Delete Your JavaScript The single biggest lever in the App Router era is shipping less JavaScript, and Server Components are how you do it wholesale. Every component that stays on the server contributes zero bytes to the client bundle — no download, no parse, no hydration cost. The practice that makes this work: **push `'use client'` boundaries to the leaves.** The recurring crime we find in audits is a page-level component marked `'use client'` because one button somewhere needs an `onClick` — which drags the entire page, and everything it imports, into the bundle. Bad: ``` // page.tsx — 'use client' at the top poisons the whole tree 'use client' import { HeavyChart } from './heavy-chart' export default function Dashboard() { ... } ``` Good — the page stays on the server, only the interactive leaf hydrates: ``` // page.tsx — Server Component (default) import { StatsGrid } from './stats-grid' // server import { ExportButton } from './export-button' // 'use client', tiny export default async function Dashboard() { const stats = await getStats() // direct DB call, no API hop return ( ) } ``` For heavy client components that are not visible on load — charts below the fold, modals, editors — add `next/dynamic` so their code loads on demand: ``` const RichEditor = dynamic(() => import('./rich-editor'), { ssr: false, loading: () => , }) ``` On one client dashboard, converting the shell to Server Components and dynamically importing two chart libraries cut first-load JavaScript from roughly 480KB to under 200KB — worth about 15 Lighthouse points on mid-range mobile before we touched anything else. ## 2. Images: Where LCP Lives and Dies In almost every audit we run, the Largest Contentful Paint element is a hero image, and fixing it follows the same recipe: - Use next/image, everywhere, no exceptions. It delivers AVIF/WebP automatically, generates responsive sizes, and enforces dimensions that prevent layout shift. - Mark the LCP image priority. Everything below the fold lazy-loads by default; the one image users see first must not. Forgetting priority on the hero is the most common single-line fix in our audits, routinely worth 0.5-1.5s of LCP. - Set sizes honestly. Without it, the browser may download a 1920px image for a 400px slot. ``` ``` Two more that people miss: keep the hero under ~200KB at source (no optimiser rescues a 4MB PNG gracefully), and never render the LCP image via CSS `background-image` — the preload scanner cannot see it, so it starts downloading late no matter how fast everything else is. ## 3. Fonts: Zero Layout Shift, No Render Blocking `next/font` solved web fonts so thoroughly that any project still using `` tags to a font CDN is leaving points on the table. It self-hosts the files (no third-party connection), inlines the `@font-face` CSS, and — the underrated part — applies size-adjusted fallback metrics so the swap from system font to web font barely moves the layout, which is where mysterious CLS usually comes from. ``` import { Inter } from 'next/font/google' const inter = Inter({ subsets: ['latin'], display: 'swap', }) export default function RootLayout({ children }) { return ... } ``` Discipline items: two font families maximum, load only the weights you actually use (every weight is another file), and prefer variable fonts when you need several weights. We have removed 300KB of unused font weights from a single project's critical path. ## 4. Third-Party Scripts: The Score Killers Here is an uncomfortable truth from our audits: **past the basics, your Lighthouse score is mostly a negotiation with your third-party scripts.** Analytics, chat widgets, session recorders, ad pixels — each one ships JavaScript that executes on your main thread during your users' first impression. The technical toolkit: - Load everything through next/script with an explicit strategy. afterInteractive for things that genuinely matter early; lazyOnload for everything else. Chat widgets, in particular, almost never deserve to load before idle. - Better still, load heavy widgets on intent — mount the chat bundle when the user hovers or clicks the launcher, not on page load. A static launcher button that swaps in the real widget on first interaction looks identical and costs nothing up front. ``` import Script from 'next/script' ``` But the higher-leverage move is organisational: put a budget on it. We run `@next/bundle-analyzer` in CI and hold a simple line — any new third-party script must name what it displaces or get an explicit sign-off on the points it costs. When we audited one marketing site, three abandoned tracking scripts nobody could name an owner for were costing 11 points. Deleting code remains the best performance technique ever invented. ## 5. Caching and Rendering Strategy The fastest server response is the one that is already rendered. Our defaults: marketing and content pages are statically generated with time-based revalidation, so they serve from the CDN edge and TTFB stops being a variable: ``` // blog/[slug]/page.tsx export const revalidate = 3600 // regenerate at most hourly ``` Truly dynamic pages (dashboards, account areas) render dynamically — but usually do not need to be in your Lighthouse-critical path, because logged-in app views are not what Google is scoring for your acquisition pages. Keep the split deliberate: static-by-default for everything public, dynamic where personalisation genuinely demands it, and `` boundaries around the slow data sections of dynamic pages so the shell streams instantly instead of the whole page waiting on your slowest query. ## 6. The Long Tail: INP and CLS Details Once LCP is under control, the remaining points hide in interaction and stability metrics: - INP suffers from long hydration and long tasks. The Server Component work in step 1 is also your INP fix — less hydration, fewer long tasks. For expensive client-side work that remains, break it up (startTransition, deferred values) so input handlers are never stuck behind a 400ms render. - CLS comes from anything sized after load: images without dimensions (solved by next/image), fonts (solved by next/font), and — the one frameworks cannot solve — content injected at the top of the page: cookie banners, announcement bars, A/B test swaps. Reserve the space in the initial layout or animate in ways that do not shift content (transform, overlay). A single late-arriving banner can push CLS past the 0.1 threshold on its own. ## 7. Lock It In: Budgets in CI The saddest audits we run are second audits — apps that hit 95 six months ago and drifted back to 74 one innocent pull request at a time. Performance is not a project, it is a property, and properties need enforcement. Two mechanisms keep the score from decaying: run Lighthouse CI on every pull request against your staging build with assertions that fail the check when a category drops below threshold, and set a hard first-load JavaScript budget per route so a bundle regression is a red build, not a surprise in next quarter's field data. The point is not the tooling — it is moving the conversation from "who broke the score?" three months later to "this PR costs 40KB, is the feature worth it?" at review time, when the answer is still cheap. ## The Order Matters If you take one thing from this post, take the sequence, because it is ranked by effect size in the audits we run: production-build measurement first, then client-boundary cleanup and dynamic imports, then the LCP image, then fonts, then a hard negotiation with third-party scripts, then rendering/caching strategy, then INP/CLS detail work. Teams that start with the details invert the effort-to-points curve and burn out at 78. And keep one honest caveat in view: Lighthouse is a proxy, not the goal. We have shipped 96-scoring pages that still *felt* slow because a critical API took two seconds — field data and real user journeys outrank the lab number every time they disagree. If your app is stuck in the 60s or 70s and you want it in the 90s without a rewrite, a performance audit is a one-to-two-week engagement for our [web development team](/services/web-development), and we hand you the prioritised list whether or not you hire us to execute it. [Book a free consultation](/contact) to get started. --- ## n8n vs Zapier vs Custom Code: Picking Your Automation Stack Source: https://fajarix.com/blogs/n8n-vs-zapier-vs-custom-code-automation Category: AI & Automation Published: 2026-06-30 > Zapier for speed, n8n for control, custom code for scale — that is the lazy summary, and it is only half right. Here is the selection framework we use in production: volume math, error-handling reality, self-hosting tradeoffs, and the specific signals that it is time to graduate to code. **Every company now runs on automations — and most are running them on the wrong layer.** We have built and inherited automation stacks across all three tiers: Zapier accounts with 80 zaps nobody fully understands, self-hosted n8n instances processing tens of thousands of executions a month, and custom queue-backed services doing work no visual tool could survive. Each layer is genuinely right for a band of problems, and the expensive mistakes happen at the boundaries — staying on a no-code tool two years too long, or writing custom infrastructure for a workflow that fires six times a day. Here is the selection framework we actually use, with the numbers. ## The Honest One-Paragraph Version Zapier wins on time-to-first-automation and breadth of pre-built integrations; it gets expensive and opaque at volume. n8n wins on control, cost at scale, and the ability to drop into code mid-workflow; it demands more technical skill and (self-hosted) real ops ownership. Custom code wins when the workflow *is* the product, when volume gets serious, or when failure genuinely costs money; it loses on iteration speed and requires engineers for every change. Most companies past 20 people should be running two of these tiers deliberately. Almost nobody should be running all three tiers for the same class of problem. ## The Selection Criteria That Actually Discriminate ### 1. Volume — do the math before choosing This is the criterion with actual arithmetic. Zapier prices per task, and every step in a zap consumes tasks. A modest workflow — trigger, filter, format, two actions — burns 4–5 tasks per run. At 200 runs a day, that is roughly 27,000 tasks a month, which lands you in Zapier tiers costing several hundred dollars monthly, climbing steeply from there. The same workload on a self-hosted n8n instance runs on a $20–40/month VPS with unlimited executions, plus the ops attention it demands. Our rule of thumb: below ~5,000 executions a month, tool cost is noise and you should optimise for convenience; above ~30,000, per-task pricing becomes a line item your CFO asks about, and the n8n/custom conversation is overdue. ### 2. Error handling — the criterion everyone discovers too late Automations fail. APIs rate-limit, webhooks arrive twice, a CRM field gets renamed. The question is not whether your stack fails but whether you find out before your customers do. Zapier's error handling is serviceable but shallow: retries and email alerts, with limited mid-flow branching on failure. n8n gives you error workflows (a dedicated flow triggered by any failure), per-node retry configuration, and manual re-execution of a failed run with its original data — that last one is genuinely valuable at 2 a.m. Custom code gives you whatever you build: dead-letter queues, idempotency keys, exponential backoff, alerting into PagerDuty. The deciding question we ask clients: **if this workflow silently failed for 48 hours, what would it cost?** If the answer is 'mild annoyance', any tier is fine. If the answer is 'lost orders' or 'compliance incident', you need at minimum n8n-with-error-workflows, and probably code. ### 3. Self-hosting and data control If workflows carry PHI, financial records, or EU data with strict residency requirements, a self-hosted n8n instance inside your own VPC changes the compliance conversation entirely — the data never transits a third party's infrastructure. Zapier offers enterprise assurances, but 'the data never leaves our network' is a sentence only self-hosting lets you say. This single factor decides the tool for most of our healthcare and fintech clients before any other criterion gets discussed. The honest cost: self-hosting means you own updates, backups, queue-mode scaling, and uptime. Budget a few hours a month of real ops attention, or use n8n's hosted cloud and accept the middle ground. ### 4. Who maintains it — the political criterion Zapier's superpower is that operations and marketing people genuinely build and fix their own automations. n8n sits in between: technical operators and developers are comfortable; most non-technical staff are not, especially once a Code node appears. Custom code means every change enters an engineering backlog behind feature work — which is precisely how a two-field change ends up taking three weeks. Match the tier to the team that will actually own the workflow, not the team that builds v1. ## Concrete Examples From Our Own Stack - Lead routing (Zapier-class problem): form submission → enrich → score → route to CRM with Slack notification. Fires 30 times a day, failure costs a slightly delayed follow-up, marketing owns the scoring rules and edits them monthly. Putting this in code would be malpractice — every rule tweak would need a deploy. - AI content pipeline (n8n-class problem): our own weekly blog automation is an 18-node n8n workflow — scheduled trigger, four content sources fetched in parallel, scoring, two LLM stages with different models, validation, duplicate-check against the live API, publish. It needs branching, custom scoring code, retry logic, and API-key management, and it changes every few weeks. Too complex for Zapier's linear model, nowhere near worth a custom service — this is the n8n sweet spot, and it has run for months at a hosting cost of effectively zero. - Document processing (code-class problem): a client pipeline ingesting thousands of PDFs daily — OCR, LLM extraction, validation against business rules, ERP writeback. At that volume with money on the line, we built a queue-backed service (BullMQ on Node, Postgres, S3) with idempotency keys, dead-letter queues, and per-stage metrics. An early n8n prototype validated the flow in week one — then we graduated it, because a visual canvas is the wrong place to manage 40 concurrent workers and exactly-once semantics. That last example encodes our favourite pattern: **prototype on the visual tier, graduate deliberately.** n8n is a superb way to discover what a workflow should be before hardening it in code. ## The Graduation Signals: When to Move to Code 1. You are fighting the tool. Workarounds for loops, state, or branching that would be five lines in a real language. When a third of your nodes are Code nodes, the canvas is costing you, not helping. 2. Volume or concurrency walls. Sustained thousands of executions daily, or long-running steps colliding with platform timeouts — Zapier's per-step limits and even n8n's single-instance defaults have ceilings you will feel. 3. Correctness requirements sharpen. Exactly-once processing, transactional writes across systems, audit trails, idempotency under retries. Visual tools can approximate these; code guarantees them. 4. The workflow becomes product. When customers see its output directly or it sits in the revenue path, it deserves tests, code review, CI, staged rollouts — the whole software discipline that visual tools structurally lack. 5. Change frequency drops, criticality rises. The inverse also matters: a stable, critical workflow gains little from a visual canvas whose main virtue is easy editing. Stability plus criticality equals code. ## The 2026 Wrinkle: AI Steps Change the Math One criterion that barely existed three years ago now shows up in most automation decisions: LLM calls inside workflows. This shifts the calculus in two specific ways. First, cost profiles invert — when a single workflow step costs 2–10 cents in model tokens, the platform's per-task fee stops being the dominant line item, which weakens the cost argument for migrating off Zapier at moderate volumes. Second, and pulling the other direction, AI steps need things visual platforms handle unevenly: prompt versioning, output validation, fallback models when a provider has an incident, and evaluation before prompt changes ship. n8n handles the mechanics well — its LLM nodes plus a validation Code node cover most patterns, and our own content pipeline swaps models per stage — but once you need eval suites and staged prompt rollouts, you have crossed into code territory regardless of volume, because the risk is no longer 'the workflow errored' but 'the workflow succeeded and produced confidently wrong output at scale.' Silent quality failure is a new failure class, and it does not appear in any platform's error logs. Our current practice: AI workflows whose output a human reviews can live on n8n indefinitely; AI workflows whose output flows directly to customers get promoted to code with an eval gate, at any volume. ## What We Recommend, By Company Shape - Under ~20 people, no dedicated engineers for internal tooling: Zapier (or Make) for everything. Your constraint is attention, not task pricing. Revisit at the first three-digit monthly invoice. - Growing team with technical operators, data sensitivity, or 10K+ executions monthly: self-hosted or cloud n8n as the default tier, Zapier retained only for the marketing-owned periphery. This is the configuration we run internally and deploy most often for clients. - Anything customer-facing, revenue-bearing, or heavy-volume: custom services with proper queues — prototyped on n8n first if the shape is uncertain. And a closing opinion that saves money: audit the stack twice a year. Automation sprawl is real — zaps nobody remembers, workflows patching processes that no longer exist. The best automation stack is not the cleverest one; it is the one where someone can tell you, for every workflow, what it does, what it costs, and who fixes it at 2 a.m. If you want help designing this stack — or an honest audit of the one that grew organically — our [AI and automation team](/services/ai-automation) builds and operates all three tiers in production. Ready to put these insights into practice? The team at [Fajarix](/contact) builds exactly these solutions. [Book a free consultation](/contact) to discuss your project. --- ## GPT vs Claude vs Gemini: Choosing an LLM for Your Product in 2026 Source: https://fajarix.com/blogs/gpt-vs-claude-vs-gemini-choosing-llm-2026 Category: AI & Automation Published: 2026-06-09 > The question is not which model tops the leaderboard this month — it is which model family fits your latency budget, cost structure, tool-use patterns, and compliance constraints. A practical selection framework from teams who integrate all three in production. Every few weeks a client asks us some version of "which AI is best — GPT, Claude, or Gemini?" and every few weeks we give the same unsatisfying answer: that is the wrong question. We integrate all three families into production systems at Fajarix, and the honest truth of 2026 is that the frontier models have converged enough on general capability that **leaderboard position is one of the least useful inputs to your decision**. Benchmarks are gamed, saturated, and refreshed faster than your procurement cycle. What actually determines whether your product succeeds with a given model is a set of much more boring properties: latency shape, cost structure under *your* traffic pattern, tool-calling reliability in *your* agent loop, and whether your compliance team will sign off. Here is the framework we actually use. ## Stop Choosing a Brand. Choose a Tier, Then a Model, Per Task. The first mental shift: every provider now ships a ladder of models — a frontier tier for hard reasoning, a fast mid tier for everyday work, and a small cheap tier for high-volume simple tasks. The differences *between tiers within one provider* are far larger than the differences *between providers at the same tier*. Most products we ship use two or three models, often from different vendors: a cheap model for classification, routing, and extraction; a mid-tier model for the main user-facing generation; a frontier model for the rare genuinely hard step. Teams that route every request to a flagship model are typically overpaying by 5-10x for the majority of their calls, and teams that force everything through a cheap model wonder why their agent falls apart on step four. ## Latency: The Constraint Product Teams Discover Too Late Latency has two components that get conflated: **time to first token** (how long the user stares at nothing) and **throughput** (how fast the rest streams). For chat UX, time to first token dominates perceived speed — users forgive a slow tail if words start appearing quickly. For agentic workloads, where output feeds the next step and nothing streams to a human, total completion time is what matters, and it compounds: a five-step agent chain at several seconds per step is a 20-30 second feature, which is a different product than a 4-second one. Practical guidance from our deployments: - If your feature is conversational, measure time to first token at p95 under your real prompt sizes — not the vendor's demo sizes. Long system prompts and fat RAG contexts push it up meaningfully on every provider. - If your feature is agentic, count the steps before you pick the model. A mid-tier model that completes each step in a second or two often ships a better product than a smarter model that doubles it — the frontier model's extra intelligence rarely survives the UX cost of six chained slow calls. - Reasoning-heavy modes on all three families trade latency for quality explicitly. They are excellent for background jobs and terrible defaults for interactive paths. Gate them behind task type, not vibes. ## Cost: Model Your Traffic, Not the Price Page Per-token prices change too often to print, but the cost *structure* is stable and it is where decisions should happen: - Know whether you are input-heavy or output-heavy. RAG and document workloads send enormous inputs and get short answers — input pricing and prompt caching dominate. Content generation is the reverse. The "cheapest" provider flips depending on which side your tokens live on. - Prompt caching is the biggest lever most teams ignore. All major providers now discount repeated prompt prefixes, on the order of full price down to a small fraction of it. Structuring prompts cache-first — static instructions and examples up front, volatile content last — has cut effective spend by 40-70% on chat-shaped workloads we have audited. This is an architecture decision, and it quietly matters more than the brand decision. - Batch tiers exist and are heavily discounted. Anything that does not need an answer in seconds — nightly enrichment, summarisation queues, eval runs — belongs on a batch endpoint at a large discount, on any provider. - Do the projection at 100x. A feature that costs $30/month in the pilot costs $3,000/month at modest success. We model cost per user action before choosing a tier, and that exercise kills more flagship-model plans than any benchmark ever has. ## Context Windows: Advertised vs Usable All three families now advertise context windows that sound infinite, and Gemini has historically pushed the largest numbers. Two cautions from production. First, **advertised context is not usable context**: retrieval quality inside a stuffed window degrades — models attend well to the start and end of very long contexts and get hazier in the middle — so "we will just paste everything in" remains a worse architecture than targeted retrieval for most workloads. Second, giant contexts are billed as giant inputs on every call; a long-context convenience that avoids building RAG can cost more per month than the RAG build. Where long context genuinely shines: single-document deep analysis (contracts, codebases, transcripts) where the whole artifact honestly matters at once. Where it disappoints: as a substitute for retrieval over a large corpus. ## Tool Use: The Real Differentiator for Agentic Products If your product is an agent — it calls tools, chains steps, edits files, hits APIs — tool-calling reliability is the axis to test hardest, because small per-step differences compound brutally. A model that follows your tool schema 98% of the time versus 93% sounds close; across a ten-step chain it is the difference between a feature and a support ticket generator. Our experience integrating all three: this is the area with the most genuine differentiation between families and between versions *within* a family, it shifts with every release, and it interacts with your specific schemas — deeply nested parameters, optional fields, and parallel calls are where models diverge. Which is why we refuse to pick on reputation: **we run every candidate model against a 50-100 case eval suite built from our client's actual tool schemas and real transcripts before committing.** Building that suite takes a few days, and it converts a religious debate into a spreadsheet — it is the single highest-leverage step in this entire post. ## Structured Output, Instruction Following, and Voice Three smaller criteria that regularly settle ties. Structured output: all providers now offer schema-enforced JSON modes; if your pipeline consumes model output programmatically, use them and stop parsing prose — reliability differences here show up in your error logs, not on leaderboards. Instruction following on long system prompts: models differ in how well they hold many constraints simultaneously deep into a conversation, and only your eval set will tell you which holds *yours*. And voice: the models have genuinely different default registers, which matters for user-facing copy. Teams develop justified preferences here — many of ours prefer Claude's default prose for customer-facing text and lean on GPT or Gemini elsewhere — but this is a taste-and-eval decision, not a spec-sheet one. ## Compliance and Deployment: Sometimes the Whole Decision For regulated clients, capability discussions are moot until these clear: data residency (where inference happens and whether contractual guarantees exist for your jurisdiction), training-data commitments (API traffic excluded from training, in writing — standard on business tiers now, but legal will want the document), certifications (SOC 2, ISO 27001, HIPAA BAAs where relevant), and cloud-marketplace availability. That last one is underrated: all three families are reachable through the major cloud platforms' model services, which means if your infrastructure and compliance posture already live on one cloud, consuming models through it inherits your existing agreements and billing — we have seen that single fact settle the provider question before any capability was discussed, and for enterprise clients that is often the correct way for it to be settled. ## Build for Switching, Because You Will Switch Our strongest architectural opinion in this space: **treat model choice as a configuration value, not a foundation.** The practical moves: route all LLM calls through one internal gateway module rather than scattering vendor SDK calls across the codebase; keep prompts in versioned files, not buried in code; keep tool schemas provider-neutral and translate at the edge; and maintain that eval suite so that when a compelling new model ships — which happens roughly quarterly now — evaluating it is an afternoon, not a migration project. Every long-running product we operate has switched at least one workload between providers in the past year, always for one of the boring reasons above: latency, cost structure, tool reliability, or compliance. Never because of a leaderboard. ## The Short Version Pick per task, not per company. Test time to first token under your real prompts. Model cost at 100x traffic with caching structured in from day one. If you are building agents, eval tool-calling on your actual schemas before you commit to anything. Let compliance veto early. And architect so that today's winner can lose next quarter without your roadmap noticing. If you want help running that evaluation against your specific product — or an integration layer that keeps you honest about switching — this is precisely what our [AI engineering team](/services/ai-automation) does. [Book a free consultation](/contact) and bring your use case. --- ## Design Systems for Startups: What to Build First (and What to Skip) Source: https://fajarix.com/blogs/design-systems-for-startups-priorities Category: Design Published: 2026-06-09 > Most startups either have no design system or a 200-component library nobody uses. Here is the build order that actually pays off — tokens first, twelve components, docs last — plus when a design system is premature and how we run Figma-to-code without the drift. **Startups get design systems wrong in two opposite directions.** Half have nothing — four shades of almost-identical grey, three different button heights, and a codebase where every modal is a fresh invention. The other half watched a conference talk and spent a quarter building a 200-component library with governance docs, which promptly went stale because the product pivoted twice. Having built design systems for our own products and for clients from seed stage to Series C, we can tell you the payoff curve is real but sharply front-loaded: the first 20% of a design system delivers about 80% of the value. This post is about which 20% to build, in what order, and what to consciously skip. ## First: When a Design System Is Premature Honest gate before anything else. If you are pre-product-market-fit with one designer and two engineers, iterating on the core product weekly, a formal design system will slow you down. Rebuilding components to spec while the product underneath them is still changing shape is how startups burn a month polishing screens that get deleted. In that phase, do exactly three things: pick a competent component library off the shelf (shadcn/ui, Radix, MUI — the choice matters less than the commitment), define your colour and spacing tokens on day one, and defer everything else. Tokens cost an afternoon and pay off forever; component libraries cost a quarter and pay off only after the product stabilises. The signal that you have crossed the threshold: the same UI pattern gets built a third time by a third person, or a second product surface appears (admin panel, marketing site, mobile app), or you hire your second designer. Any of those, and the duplication tax now exceeds the system-building cost. That typically lands somewhere between 5 and 15 people building product — not before. ## Phase 1: Tokens (Week One, Not Month Three) Design tokens are the named decisions — colours, type scale, spacing, radii, shadows — expressed as variables that both Figma and code consume. They are the highest-leverage artifact in the entire discipline because they are cheap to define and expensive to retrofit. Our starter set, which has barely changed across a dozen projects: - Colour: one brand palette with 9–10 steps, one neutral ramp, and four semantic roles (success, warning, danger, info) — then aliased semantic tokens on top: surface, surface-raised, text-primary, text-muted, border, accent. Components reference the aliases, never the raw palette. This single indirection is what makes dark mode a two-day job instead of a six-week one. - Spacing: a 4px base scale. Twelve values, no exceptions granted in code review. Arbitrary spacing is the fastest way a UI starts looking subtly broken. - Typography: one, at most two typefaces; a six-step modular scale; three weights. Every text style in Figma maps 1:1 to a code token. - Radii and elevation: three radius values, three shadow levels. More than that and nobody can tell them apart anyway. Implementation detail that matters: define tokens once in a neutral format and generate both platforms from it — CSS variables (or a Tailwind theme) for code, Figma Variables for design. Whether you use Style Dictionary or a 60-line script, the point is a single source of truth. The moment tokens are maintained by hand in two places, they diverge, and divergence is the beginning of the end. ## Phase 2: The Twelve Components That Earn Their Keep Component-building effort follows a power law: a dozen components appear on virtually every screen, and the long tail appears twice a year. Build the head, buy or improvise the tail. Our standard first twelve: Button, Input (with label, error, and help text as one composed unit — not four loose pieces), Select, Checkbox/Radio/Switch, Modal, Toast, Card, Table, Tabs, Badge, Avatar, and an Empty State pattern. That last one is the sleeper — empty states appear on every list view, and teams without a pattern ship blank white voids. Three rules that keep this phase from bloating: 1. Extract, don't speculate. A component enters the system after it exists in the product twice, built from the best existing instance. Components designed in the abstract for imagined future use cases are consistently the ones with the wrong API. 2. Build on primitives, not from scratch. In 2026 there is no defensible reason for a startup to hand-roll focus traps, keyboard navigation, and ARIA wiring. We build brand-styled components over headless primitives — Radix UI or React Aria — and get accessibility approximately correct for free. Hand-rolled modals are where accessibility goes to die. 3. Cap variants ruthlessly. A Button needs three variants and three sizes: nine combinations. We have inherited a system whose Button had 47 variant combinations; the team feared touching it, so they built new buttons beside it — the exact failure the system existed to prevent. If a variant is used once, it is not a variant, it is a one-off, and one-offs are allowed to live outside the system. ## Phase 3: Documentation — Less Than You Think, Later Than You Think For a startup-scale system, heavyweight docs sites are a trap. The documentation that actually gets read: a Storybook (or equivalent) with every component in every state, usage-note one-liners on the Figma components ('use Danger only for destructive actions'), and a single do/don't page for the five most-misused patterns. That is it. We have watched teams spend six weeks on beautifully written design-system portals with analytics showing eleven total visits. Your system's real documentation is the components themselves plus the ability to ask in Slack; write down only what people repeatedly get wrong. ## The Figma-to-Code Workflow That Prevents Drift A design system dies when Figma and code disagree and nobody notices for a quarter. Our working setup: - Same names on both sides. The Figma component Button/Primary/Md corresponds to