DEV Community: Doktouri

Fixed price vs time & materials

Doktouri — Wed, 08 Jul 2026 23:29:54 +0000

The contract you sign with a software team shapes the project as much as the code does. It decides who carries the risk, how welcome change is, and which incentives quietly pull on both sides. Fixed price and time & materials are the two dominant models, and neither is universally better — the right one depends entirely on how much uncertainty your project carries.

Fixed price: certainty bought with rigidity

In a fixed-price deal you agree a defined scope for a defined amount. The team carries the risk of overrun. That certainty is appealing, and for the right project it's the correct choice — but it comes with strings.

Fixed price only works when scope is genuinely well understood up front. To protect against the unknowns, the team prices in a risk buffer, so you often pay more for the certainty. And because any change threatens their margin, change requests turn into negotiations. The model quietly incentivizes matching the spec, not finding the best solution.

Fixed price fits when: the scope is clear and stable, you need budget certainty, and the work is well-trodden rather than exploratory.

Time & materials: flexibility that demands trust

Under time & materials you pay for the effort spent, usually at an agreed rate. Scope can flex as you learn. The client carries the budget risk, but gains the freedom to change direction without renegotiating a contract every time.

The upside is honesty of incentives: the team is free to build the right thing rather than defend a fixed scope, and you're not paying a padded buffer for risk that may never materialize. The downside is that it requires trust and active involvement — an absent client on a T&M contract can watch costs drift.

Time & materials fits when: scope is uncertain or evolving, discovery is ongoing, and you want the flexibility to steer as you learn.

The incentive question nobody asks

Look past the price to what each model rewards. Fixed price rewards delivering the agreed scope — even if you learn mid-build that a different scope would serve users better. Time & materials rewards doing valuable work — but only pays off if you stay engaged enough to keep that work pointed in the right direction. Match the incentive to the reality of your project.

Caps, phases, and hybrids

The models aren't a hard binary. Sensible middle grounds exist:

Capped T&M — bill for time but agree a ceiling, sharing the risk.
Fixed-price discovery, then T&M build — nail down scope cheaply first, then flex.
Phased fixed price — fix the price of a well-understood slice, re-scope for the next.

These often beat either pure model, especially early when uncertainty is highest.

How to choose in one question

Ask: how well do I understand what needs to be built? If the answer is "very well, and it won't change much," fixed price gives you certainty. If it's "we'll learn a lot as we go," time & materials — ideally capped — keeps you free to build the right thing.

At Doktouri we structure engagements around the actual uncertainty in your project, not a one-size template. If you're weighing how to contract a build, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

Is Expo production-ready in 2026?

Doktouri — Wed, 08 Jul 2026 23:29:20 +0000

The old advice was "start with Expo, then eject when you hit its limits." That advice is out of date. Expo has evolved from a convenient sandbox into the recommended, production-grade way to build React Native apps — and the "eject" concept is essentially gone. If you're evaluating it on reputation from a few years ago, here's the honest 2026 picture.

What changed

Two developments moved Expo from prototype tool to production platform:

The dev client and config plugins. You're no longer limited to a fixed set of built-in native modules. Any native library works, and config plugins let you customize the native project declaratively. The hard wall that used to force ejection is gone.
EAS (Expo Application Services). Cloud build, submission, and — crucially — over-the-air updates turned Expo into an end-to-end delivery pipeline, not just a starter kit.

The modern flow is "prebuild," which generates native projects you fully control while keeping Expo's tooling. There's no dramatic one-way eject anymore.

Where Expo genuinely shines

EAS Build removes the misery of local iOS/Android build environments, certificates, and signing — it builds in the cloud
EAS Update ships JavaScript-only fixes over the air, bypassing store review for many changes (within platform rules)
EAS Submit automates uploads to both stores
The file-based router (Expo Router) brings clean, typed navigation
Excellent developer experience and fast iteration

For most React Native apps, this toolchain saves weeks of undifferentiated setup and maintenance work.

The real limits

It's not magic. Be aware of:

Fully custom native code. You can write and integrate any native module via config plugins, but if your app is native-heavy with lots of bespoke native work, you take on real complexity — Expo helps less there.
Cost at scale. EAS is generous but paid past its free tier; heavy build volume has a cost. You can also self-host builds if needed.
Bleeding-edge native APIs. A brand-new OS API without a community module yet may need you to write the native binding yourself.
App size. Expo apps can be slightly larger, though this has improved and is rarely a real problem.

None of these are blockers for the vast majority of apps.

When to use it — and when to think twice

Use Expo (this is our default for new React Native apps) when:

You want to move fast and avoid native build-environment pain
Over-the-air updates and streamlined store submission are valuable
Your app is standard-to-moderately-custom — the common case

Think harder when:

The app is dominated by heavy, custom native code and hardware integration
You have very specific native performance or platform requirements Expo doesn't yet smooth over

The verdict

Expo is production-ready and then some. Major apps ship on it, the eject-fear is obsolete, and for most teams it's the fastest path to a maintainable React Native app. Reach past it only when your product is genuinely native-heavy in ways the tooling can't streamline.

If you're starting a React Native app and want it built on a modern Expo/EAS pipeline that ships fast and updates over the air, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

E-commerce conversion optimization that moves revenue

Doktouri — Wed, 08 Jul 2026 23:23:40 +0000

Most conversion advice is a pile of tips with no ranking, so teams burn weeks A/B testing button colors while their checkout leaks money on mobile. Conversion optimization works when you fix the biggest leaks first. This is the order we'd actually work in — highest revenue impact at the top, vanity tweaks at the bottom.

1. Fix checkout friction first

Checkout is where intent turns into revenue, and where most of it dies. Every extra field, forced account creation, or surprise cost at the last step sheds buyers who were ready to pay.

Offer guest checkout — never force account creation before purchase.
Show total cost, including shipping, as early as possible. Surprise fees are the top abandonment cause.
Support Apple Pay, Google Pay, and Shop Pay so returning buyers skip the form entirely.
Keep it to as few steps as the flow allows, with a visible progress indicator.

This is almost always the single highest-leverage area. Start here.

2. Make the store fast

Speed is conversion. A store that takes several seconds to become interactive loses buyers before they see a product. Chase Core Web Vitals — LCP, INP, CLS — as a revenue metric, not a technical one.

Compress and lazy-load images, ship less JavaScript, and serve from a CDN. On mobile especially, every second of load time is measurable lost revenue.

3. Earn trust above the fold

Shoppers decide fast whether a store is legitimate. Reduce that friction:

Real product photography and clear, honest descriptions.
Reviews and ratings on product pages.
Visible return policy, shipping timelines, and support contact.
Security and payment badges near the buy button.

Trust signals don't feel like CRO, but they move the numbers.

4. Design for the thumb

Most traffic is mobile, yet many stores are still designed desktop-first. Tap targets should be large, the add-to-cart button should stay reachable, and forms should use the right mobile keyboards. Test the entire purchase on a real phone, on real mobile data — not just a resized browser window.

5. Recover the carts you lose

Not every abandonment is preventable. Win some back with automated abandoned-cart emails and, where appropriate, exit-intent offers. A well-timed reminder recovers a meaningful slice of otherwise-lost orders at almost no cost.

Measure like it's revenue, not opinions

Instrument the funnel — product view, add to cart, checkout start, purchase — so you can see exactly where buyers drop. Change one thing, measure the segment it affects, and keep what wins. Optimization without measurement is just redecorating.

At Doktouri we treat conversion as an engineering problem: measurable, testable, and tied to revenue. If your store gets traffic but not enough orders, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

Docker for developers

Doktouri — Wed, 08 Jul 2026 23:23:07 +0000

"Works on my machine" is the most expensive sentence in software. Docker exists to kill it. At its core, Docker packages your application together with everything it needs to run — the runtime, libraries, and system dependencies — into a single portable unit that behaves identically on your laptop, a teammate's machine, and production. Once the concepts click, it stops feeling like mysterious DevOps magic and becomes a tool you reach for daily.

Images and containers: the core idea

Two words do most of the work:

An image is a blueprint — a read-only snapshot of your app and its environment, built from a Dockerfile\.
A container is a running instance of that image — a lightweight, isolated process.

The analogy: an image is like a class, a container is like an object you instantiate from it. You build an image once and run many containers from it. Unlike a virtual machine, containers share the host kernel, so they start in milliseconds and use a fraction of the resources.

Understand layers, and your builds get fast

A Dockerfile\ is a list of instructions, and each one creates a layer that Docker caches. This is the single most useful thing to understand for a good workflow: order your instructions from least to most frequently changing.

In practice, copy your dependency manifest and install dependencies before copying your application code:

\COPY package.json package-lock.json ./ RUN npm ci COPY . . \\

Because your source changes far more often than your dependencies, Docker reuses the cached install layer on every rebuild and only re-runs the fast steps. Get this order wrong and every one-line change reinstalls everything.

Keep images small with multi-stage builds

Big images are slow to push, pull, and deploy — and they carry a larger attack surface. Multi-stage builds let you compile or bundle in a fat "builder" stage, then copy only the finished artifacts into a slim final image. Start from a minimal base like an alpine\ or slim\ variant, and don't ship your build tools to production. A lean image is a faster, safer image.

Compose ties the whole app together

Real apps aren't one process. You've got your API, a PostgreSQL database, maybe Redis for caching. Docker Compose describes all of them in a single docker-compose.yml\ and starts them together with one command. A new developer clones the repo, runs docker compose up\, and has the entire stack running locally in minutes — no page of setup instructions, no version mismatches, no "did you install Postgres 16?" This alone justifies adopting Docker.

Where it pays off most

The workflow that makes teams faster looks like this:

Define the environment once in a Dockerfile\ and docker-compose.yml\.
Every developer runs the identical stack locally — no drift.
CI builds and tests the same image you'll deploy.
That exact image ships to production.

The same bytes run everywhere, so a whole category of environment bugs simply stops existing. You don't need to master every Docker flag to get this benefit — the fundamentals here cover the vast majority of real development.

If your onboarding still involves a wiki page of setup steps, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

Design systems for startups

Doktouri — Wed, 08 Jul 2026 23:16:42 +0000

A design system sounds like something you earn later — a luxury for companies big enough to have a design-systems team. For a startup that's exactly backwards. A right-sized system is what lets three people ship a coherent product fast, without re-deciding the same button padding on every screen. The trap isn't building one too early; it's building a heavyweight one you don't need. The answer is to start tiny and grow it only as it earns its keep.

Start with tokens, not components

Before any component library, agree on the primitives everything else is built from — the design tokens:

A small color palette with defined roles (primary, surface, text, danger).
A type scale — a handful of sizes, not a dozen.
A spacing scale, so margins and padding come from a set, not from guesses.
Consistent border radius and shadow values.

Tokens are cheap to define and pay off immediately: every screen built from the same primitives looks like the same product, automatically. This is the highest-leverage step, and most teams skip straight past it.

Build components only when you repeat yourself

Don't sit down to design fifty components. Build one the second time you copy-paste it. The button, input, card, and modal you use everywhere are worth standardizing. The one-off nobody reuses is not. Let real repetition, not an imagined future, decide what becomes a component.

Use tooling that fits your size

You don't need a bespoke pipeline. Lean on what already exists:

A component library like shadcn/ui or Radix gives you accessible, unstyled primitives to theme with your tokens.
Tailwind CSS maps naturally onto a token system through its config.
Keep tokens in one place — CSS variables or a shared config — so a single change propagates everywhere.

The goal is leverage, not a platform. If your design system needs a maintainer, it's too big for your stage.

Document just enough

A full documentation site is overkill early. What you need is a single source of truth — a page, a Storybook, or a shared file — that answers "what do we already have and how do I use it?" so people reuse instead of reinventing. Documentation that nobody maintains is worse than a short one that's always current.

Let it grow with the product

A startup design system should feel slightly incomplete, always. You add to it as real needs appear, not in anticipation of them. When a pattern shows up three times, promote it into the system. When something in the system stops being used, remove it. It's a living tool, not a monument.

Consistency is a speed feature

The reason to do any of this isn't aesthetics — it's velocity. When primitives are decided and components are reusable, designers and developers stop re-litigating the basics and spend their time on the parts of the product that actually differentiate you. A good design system makes a small team feel larger.

At Doktouri we build right-sized design systems that make startup teams faster without the overhead of a big-company setup. If your product's UI is drifting as you grow, talk to us.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

Database indexing explained

Doktouri — Wed, 08 Jul 2026 23:16:08 +0000

Almost every "the database is slow" complaint we investigate comes down to a missing or misused index. Indexing is the highest-leverage performance skill a developer can have, and yet it's often treated as arcane. It isn't. Once you understand what an index actually is and how to read a query plan, you can turn a ten-second query into a ten-millisecond one on purpose instead of by luck.

What an index actually is

Think of an index like the index at the back of a book. Without it, finding every mention of a topic means reading every page — a sequential scan. With it, you jump straight to the right pages. In a database, an index is a separate, sorted data structure that lets the engine find rows without examining the whole table.

Most indexes are B-trees, which keep values sorted so the database can binary-search them. That's why a B-tree index speeds up equality (=\), ranges (<\, >\, BETWEEN\), sorting, and prefix matches — but does nothing for a leading-wildcard LIKE '%foo'\.

Index what you filter, join, and sort on

The rule of thumb: any column that regularly appears in a WHERE\ clause, a JOIN\ condition, or an ORDER BY\ is a candidate for an index. Foreign keys are almost always worth indexing, since you'll join on them constantly.

For queries that filter on multiple columns, a composite index on several columns together beats separate single-column indexes. But column order matters: an index on (tenant_id, created_at)\ helps queries filtering by tenant_id\ alone or by both — but not queries filtering by created_at\ alone. Put the most selective, most-often-filtered column first.

Learn to read EXPLAIN

You never have to guess whether an index is used. In PostgreSQL, run EXPLAIN ANALYZE\ on your query and read the plan:

Seq Scan on a large table in a hot query is a red flag — the database is reading everything.
Index Scan or Index Only Scan means your index is doing its job.
The reported row estimates versus actual rows tell you whether the planner's statistics are accurate.

Make EXPLAIN ANALYZE\ a reflex before and after adding an index. It turns performance work from folklore into measurement.

Indexes aren't free

It's tempting to index everything, but each index has a cost. Indexes take disk space, and — more importantly — every INSERT\, UPDATE\, and DELETE\ has to update every affected index. Over-indexing a write-heavy table slows down exactly the operations you care about.

So index deliberately:

Add indexes to support real, measured slow queries — not hypothetical ones.
Periodically drop indexes that nothing uses (Postgres tracks index usage stats).
Watch for redundant indexes where a composite index already covers a single-column one.

Build the habit

The whole discipline fits in one loop: write the query, run EXPLAIN ANALYZE\, add the index the plan is begging for, and measure again. Do that consistently and slow-database fire drills mostly disappear from your life. The teams that struggle aren't missing some secret — they've just never looked at a query plan.

If your app is crawling and you suspect the database, talk to us.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

Custom e-commerce vs Shopify

Doktouri — Wed, 08 Jul 2026 23:07:41 +0000

Most brands should start on Shopify. That's not a concession — it's the fastest way to a working store with payments, tax, shipping, and a checkout that converts. The real question isn't whether Shopify is good; it's whether your specific business hits a wall that only a custom build can clear. Answer that honestly and you avoid the two expensive mistakes: premature engineering (rebuilding solved problems to feel in control) and platform lock-in you've outgrown (paying in lost margin and blocked roadmap to avoid a migration). This is a decision framework, not a verdict — because the right answer genuinely depends on your business.

What Shopify does better than you will

Shopify's checkout is battle-tested across millions of orders and continuously optimized by a team larger than most companies. Fraud tooling, PCI compliance, one-click Shop Pay, dozens of payment methods, address validation, and abandoned-cart recovery come essentially free. Rebuilding that from scratch is many months of work that adds zero differentiation — nobody buys from you because you wrote your own checkout, and a checkout bug costs you real orders.

Beyond checkout, you're renting a whole operational stack: inventory management, order routing, a mature app ecosystem, tax calculation across jurisdictions, and hosting that survives a Black Friday spike without you touching a server. That last point is easy to underrate — the day your product goes viral or a campaign lands, Shopify absorbs a 50x traffic spike automatically, while a custom store meets that same moment as an on-call incident. Platforms also ship improvements you inherit for free: new payment methods, checkout optimizations, fraud-model updates, compliance changes across regions. On a custom build, every one of those is a ticket in your backlog.

For a catalog of a few thousand SKUs and standard fulfillment, Shopify plus a few well-chosen apps will outperform anything a small team ships in a quarter. If your storefront is a fairly conventional catalog-and-cart, stay on Shopify and put your energy into product, brand, and acquisition — the things that actually grow revenue.

The signals that you've outgrown it

Custom starts to pay off when your business logic stops fitting the template. Watch for these:

Complex pricing or configuration — quote-based B2B, per-customer catalogs, volume tiers, or products assembled from many interdependent options (a configurator). Shopify's variant model caps out, and the app workarounds get brittle.
App sprawl — you're paying for a dozen apps that overlap, conflict, slow the store down, and still don't do quite what you need. The monthly app bill plus the maintenance burden of keeping them compatible starts to rival a custom feature.
Margin at scale — at high GMV, platform fees plus transaction fees (especially if you're not on Shopify Payments) become a real line item. At tens of millions in GMV, reclaiming those points can fund the engineering.
Unique fulfillment or inventory — multi-warehouse routing, marketplace/multi-vendor logic, complex subscriptions, rentals, or bundles with rules no app models cleanly.
Deep systems integration — a custom ERP, a specialized 3PL, or an internal tool that Shopify's APIs can only awkwardly reach.

One of these alone is rarely enough to justify a rebuild — there's usually an app or a workaround. Two or three together, each costing you real money or blocking real revenue, is a genuine signal.

Score it honestly before you commit

Founders talk themselves into custom builds because building feels like progress, and out of them because migration feels scary. Neither instinct is a business case. Before you spend a dollar, run a blunt scoring exercise across the dimensions that actually decide this:

Control — how much of the customer experience does the platform prevent you from shaping? On a conventional store, very little. On a novel one, a lot.
Cost curve — plot your platform, app, and transaction fees against projected GMV for the next 24 months. Custom flips from wasteful to smart at a specific revenue point; find yours.
Speed — Shopify ships you a feature today; custom ships it in a sprint. Early on, speed usually wins outright.
Risk — a custom checkout is your uptime, your PCI scope, your incident at midnight. Price that risk in, don't wish it away.
Team — do you have (or will you retain) the engineering capacity to own a store forever, not just ship one?

If custom only wins on "control" and loses on the other four, you have your answer. The brands that replatform successfully can point to a specific, quantified constraint the platform imposes and a specific number the rebuild unlocks.

The middle path most teams miss

It's not binary, and treating it as binary is the most common mistake we see. Headless commerce lets you keep a commerce engine — Shopify via its Storefront API, or an open engine like Medusa or commercetools — as the backend, while building a fully custom React or Next.js front end. You get complete design and performance freedom, the SEO benefits of server-side rendering, and pages that hit the Core Web Vitals targets that both convert and rank — all without rebuilding checkout, inventory, or payments.

For many growing brands this is the right answer: custom where it differentiates (the storefront experience, the content, the speed), managed where it doesn't (the money-touching core). Our headless commerce guide walks through the architecture and the trade-offs in depth. The catch is real, though — headless means you now own the front end's performance, deployment, and complexity, so it's a step up in engineering commitment, not a free lunch.

What a custom build actually costs

A custom store isn't just the initial build, and founders who budget only for the launch get an unpleasant surprise. You own security patches, dependency upgrades, payment-processor API changes, tax-rule updates, PCI scope, and uptime — forever. When a payment provider deprecates an API or a new tax rule lands, that's your engineering time, on your schedule, at your cost. Budget for a maintenance retainer, not just a launch, and staff for the incident at 2 a.m. during your biggest sale.

The math works when custom capability drives revenue or reclaims margin that comfortably exceeds that ongoing cost — and rarely before. If you can't point to a specific number the custom build unlocks, you're probably rebuilding for control, not returns.

There's also an opportunity cost that never shows up on the invoice. Every engineer-month spent rebuilding a checkout that Shopify already gives you for free is a month not spent on the thing only your team can build — the feature that differentiates you, the acquisition channel that grows you. For an early brand, that's usually the most expensive line of all, precisely because it's invisible.

Don't replatform to fix a problem a platform can solve

The most common regret we see isn't a custom build that failed technically — it's a custom build that solved a problem the brand could have solved on Shopify for a fraction of the cost. Slow store? That's usually a theme, an app-bloat, or an image problem, not a platform ceiling. Can't get the design you want? A headless front end fixes that without touching commerce. Conversion stalling? That's a merchandising and UX problem the conversion optimization playbook addresses far more cheaply than an engineering team. Exhaust the platform's real limits before you conclude you've hit them.

A simple decision rule

Start on Shopify. Validate the business. Ship fast. Spend on brand and acquisition, not infrastructure.
Move to headless when design and performance are genuinely holding you back but your commerce logic still fits a platform. Keep the money-plumbing managed.
Go fully custom only when your business model itself doesn't fit any platform — and the revenue or reclaimed margin clearly justifies owning the whole stack, maintenance included.

If you do move off Shopify, migrate in stages rather than in one high-stakes cutover. Go headless first — keep the commerce engine, replace only the front end — and prove the new storefront converts before you touch the money-plumbing. Preserve your URL structure and 301-redirect anything that changes, or you'll hand back months of hard-won SEO the day you launch. Keep the old store live until the new one is measurably at least as good on conversion and page speed. A replatform that tanks organic traffic or checkout conversion can erase years of margin gains overnight, so treat the migration itself as a first-class project with its own budget and rollback plan, not an afterthought to the build.

Whichever direction you lean, don't forget the fundamentals that move the number that matters: our e-commerce conversion optimization guide will usually find more revenue than a replatform will, and it's a fraction of the cost.

At Doktouri we've shipped both Shopify storefronts and fully custom commerce platforms, so we have no incentive to push you toward the more expensive answer — we can tell you which one your business actually needs. If you're weighing the move, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

A developer's guide to Core Web Vitals

Doktouri — Wed, 08 Jul 2026 22:49:37 +0000

Core Web Vitals are Google's attempt to quantify what "fast" feels like, and they feed into search ranking. There are three: LCP measures loading, INP measures responsiveness, and CLS measures visual stability. Passing them isn't about a single trick — it's about understanding what each one measures and fixing the specific things that break it.

LCP — Largest Contentful Paint

LCP is the time until the biggest element in the viewport (usually a hero image or headline block) finishes rendering. Aim for under 2.5 seconds. Common causes of a bad LCP:

A large, unoptimized hero image
Render-blocking CSS or JavaScript in the <head>\
Slow server response (high TTFB)
Web fonts that delay text rendering

Fixes: serve modern image formats (WebP/AVIF) at the right size, preload the LCP image, inline critical CSS, and render HTML on the server so the browser has something to paint immediately. If your TTFB is high, the problem is upstream — caching or hosting, not the front end.

INP — Interaction to Next Paint

INP replaced First Input Delay and is stricter. It measures the latency of interactions across the whole page visit — click a button, how long until the screen visibly responds? Aim for under 200 milliseconds. Bad INP almost always means the main thread is blocked by JavaScript.

Fixes:

Break up long tasks so the browser can respond between them
Ship less JavaScript — code-split and lazy-load what isn't needed on first load
Defer non-critical work with requestIdleCallback\ or by yielding to the main thread
Avoid heavy synchronous work in event handlers

INP is the metric most sites fail after the recent shift, and it's usually a symptom of too much client-side JavaScript.

CLS — Cumulative Layout Shift

CLS measures unexpected movement — content jumping as the page loads. Aim for under 0.1. The usual culprits:

Images and embeds without width and height attributes
Ads or banners injected above existing content
Web fonts causing a reflow when they swap in
Content inserted dynamically without reserved space

Fixes: always set explicit dimensions or an aspect-ratio on media, reserve space for anything that loads late, and preload fonts with font-display: optional\ or swap\ chosen deliberately.

Measure with the right tools

There's a critical distinction: field data (real users, in Google's CrUX report) is what actually affects ranking, while lab data (Lighthouse, one synthetic run) is just a diagnostic. A green Lighthouse score means nothing if real users on slow phones are failing.

Use PageSpeed Insights to see both field and lab data for a URL.
Use the web-vitals JavaScript library to collect real INP and LCP from your own users.
Watch Search Console's Core Web Vitals report for trends across your whole site.

The order of operations

Fix LCP first (it's usually the biggest win and touches SSR and images), then INP (reduce JavaScript), then CLS (reserve layout space). Treat it as ongoing hygiene, not a one-time audit — a single heavy third-party script can undo months of work.

If your Search Console is flagging poor vitals and you want them green without a rewrite, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

Setting up a CI/CD pipeline

Doktouri — Wed, 08 Jul 2026 19:46:52 +0000

The difference between a team that ships daily and one that dreads every release usually isn't talent — it's the pipeline. A good CI/CD setup turns deployment from a nerve-wracking event into a non-event that happens dozens of times a day. The goal is simple: every commit is automatically proven safe and can reach production without a human babysitting it. Here's how we build that.

Continuous integration: catch problems before merge

CI runs on every push and pull request, and its job is to fail loudly and early. A solid pipeline runs these stages, fastest first:

Lint and format checks — cheap, instant feedback on style and obvious mistakes.
Type checks — with TypeScript, this catches a whole class of bugs before any test runs.
Unit and integration tests — the core safety net; keep them fast so people don't route around them.
Build — prove the app actually compiles and packages into a deployable artifact.

Order matters. Run the quick checks first so a lint failure doesn't wait ten minutes behind the test suite. Keep the whole run under about ten minutes, or developers will start ignoring it.

Build once, promote the same artifact

A common mistake is rebuilding the application separately for staging and production. Don't. Build a single artifact — a Docker image is ideal — and promote that exact image through environments. If it passed tests in staging, the identical bytes go to production. This eliminates the "it worked in staging" class of bug entirely.

Continuous delivery: automate the boring, gate the scary

For most teams, merging to the main branch should automatically deploy to staging. Production can be one click behind that, or fully automated once you trust your tests. The key is that deployment is a script, not a runbook a person follows by hand at midnight.

Use a safe rollout strategy so a bad release doesn't take everyone down at once:

Blue-green deployments keep the old version warm so you can switch back instantly.
Canary releases send a small slice of traffic to the new version first and watch the metrics.

Make rollback a first-class button

Everything fails eventually. What separates calm teams from panicking ones is how fast they recover. Your rollback should be a single, well-tested command that reverts to the last known-good version in seconds. If rolling back is scary or slow, you'll hesitate exactly when speed matters most. Rehearse it before you need it.

Guard the secrets and the branch

Never bake secrets into images or logs — inject them at runtime from a secrets manager. Protect your main branch: require passing checks and review before merge, so the pipeline is the only path to production and no one can push around it. These two rules prevent most self-inflicted outages.

Start small and grow

You don't need the full setup on day one. Begin with automated tests on every PR and one-command deploys. Add canary rollouts and richer monitoring as the stakes rise. Even a minimal pipeline — tests plus automated deploy — transforms how a team works, because it turns "did I break something?" from a fear into a fact the machine answers for you.

If your releases still involve held breath and manual steps, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

How to choose a tech stack for your startup

Doktouri — Wed, 08 Jul 2026 19:46:18 +0000

Choosing a tech stack is one of the few early decisions you'll live with for years, yet founders often make it by copying whatever a popular blog post recommended last month. The right stack isn't the newest one — it's the one your team can ship in, hire for, and still be productive with after the honeymoon ends. A stack is a set of bets about your future: how fast you'll grow, who you'll hire, what your product becomes. Get the bets roughly right and the code almost writes itself. Get them wrong and you spend your second year fighting the decisions of your first. Here's the framework we actually use.

Start with the team you have

The single biggest predictor of velocity is whether your engineers already know the stack. A senior team that's fast in TypeScript and PostgreSQL will out-ship a team fumbling through an unfamiliar "better" language every time. Familiarity compounds: it's not just syntax, it's knowing the debugger, the testing patterns, the deployment quirks, the libraries that are actually good versus the ones with great READMEs and abandoned issue trackers. Optimize for the tools your people are dangerous in today, not the ones you'd pick in a vacuum.

If you're hiring soon, factor in the labor market. A stack with a deep talent pool — TypeScript, Python, React — means you can staff up quickly and cover for a departure without a crisis. An exotic choice (Elixir, Rust on the web, a niche framework) narrows your funnel to a handful of specialists who cost more, take longer to find, and are harder to replace when one leaves. That's a fine trade if the technology is genuinely core to your product's value. It's a terrible trade if you picked it because it was interesting.

There's a subtler cost too: onboarding. A new hire on a mainstream stack is productive in days. On an unusual one, weeks. Multiply that across every engineer you'll ever add and the "boring" choice quietly wins on total cost.

Match the stack to the problem, not the trend

Ask what your product actually needs before reaching for anything fancy:

Data-heavy and relational? A boring, reliable PostgreSQL database will take you further than any trendy alternative. It does JSON, full-text search, geospatial queries, and transactional integrity in one engine — see PostgreSQL for startups for why it's the default we reach for.
Real-time or collaborative? Look at Supabase for managed real-time subscriptions, or plan a websocket layer early rather than bolting one on later. Our realtime features architecture guide covers the patterns.
Content-driven web app? Next.js with server-side rendering gives you SEO without a separate CMS. If organic traffic matters, read why server-side rendering still wins for SEO before you commit to a client-only SPA.
Standard CRUD API? A NestJS service on Node keeps structure without ceremony, and it shares a language with your front end so context-switching is cheap.
AI or search features? You'll want vector storage. Postgres with the pgvector extension covers most needs before you reach for a dedicated vector database.

Most products are more ordinary than their founders think. The novelty lives in the product idea and the go-to-market, not in the plumbing. Ordinary problems deserve proven tools.

Favor boring, well-supported technology

For an early-stage company, boring is a feature. Mature technologies have documentation, Stack Overflow answers, hardened libraries, LLM training data (your AI pair-programmer is far more useful on a popular stack), and known failure modes. Bleeding-edge tools have GitHub issues and a Discord where the maintainer promises a fix "soon."

The test we apply: has someone already hit the problem you're about to hit, and written it down? With Postgres, React, or Node, the answer is almost always yes. With a two-year-old framework, you're the QA team. Reserve your innovation budget — and every team has a limited one — for the product itself. Every unusual infrastructure choice is a tax you pay on every future hire, every debugging session, and every 2 a.m. incident when the one person who understood it is asleep or gone.

This isn't an argument against ever adopting new tools. It's an argument for spending your novelty where it earns its keep. Pick one thing to be adventurous about, if you must, and make everything around it dependable.

The build-vs-buy default

A modern stack is as much about what you don't build. Auth, email delivery, payments, file storage, background jobs, error tracking — every one of these is a solved problem you can rent. Managed services (Supabase, Clerk, Stripe, Resend, Sentry) cost real money at scale, but at the stage where you're choosing a stack, engineering time is far more expensive than a SaaS invoice. Build the thing that's yours; buy the thing that's everyone's. You can always bring a service in-house later once it's a proven cost center — that's a good problem to have.

Design for two years, not two months

The trap sits on both ends. Kubernetes and microservices for a pre-launch product is premature complexity: you inherit the operational burden of a company ten times your size while serving zero users. But a stack that physically can't grow — a database that won't scale, a no-code tool you'll have to rip out at 10,000 users, a framework with a hard ceiling — is a false economy that mortgages your future for a fast start.

The sweet spot is a modular monolith on managed hosting: a single deployable app with clean internal boundaries, simple enough to move fast now, structured enough to split apart later if you genuinely need to. You almost never need to decide microservices vs monolith on day one — and if you're tempted, our microservices vs monolith breakdown will probably talk you out of it. Draw module lines where your domains actually separate (billing, users, the core product), keep them talking through well-defined interfaces, and you'll have the option to extract a service the day the traffic justifies it — not before.

A worked example: the default stack we reach for

To make this concrete, here's the stack we hand most early-stage web products, and the reasoning behind each choice — not because it's universally correct, but because it's a defensible default you'd need a specific reason to deviate from:

TypeScript everywhere. One language across front end, back end, and shared validation. Types catch a whole class of bugs before runtime and make refactoring safe, which matters most exactly when you're changing things fastest.
Next.js for the web front end. Server rendering for SEO, a mature ecosystem, and a hosting story that's a git push. If you're weighing it against plain React, Next.js vs React lays out when the extra framework earns its keep.
PostgreSQL for data. Relational integrity, JSON when you need flexibility, and it scales further than most startups ever test.
Supabase or a NestJS API for the backend. Managed auth, storage, and real-time out of the box, or a structured Node API when you need more control. Compare the managed options in Supabase vs Firebase.
Managed hosting, one deployable app. No Kubernetes, no service mesh, no ops team you don't have.

This stack has a deep talent pool, excellent documentation, strong AI-assistant support, and a clear upgrade path. That combination — not any single tool's cleverness — is what makes it a good bet. Deviate deliberately, for a reason you've written down, not by default.

Common mistakes we see

Resume-driven development. Choosing a technology because it's good for the engineer's career, not the product. It's an understandable instinct and a costly one.
Optimizing for a scale you don't have. Architecting for a million users while you're chasing your first hundred. The million-user rewrite is a luxury problem; ship first.
Fragmenting the language. A Go backend, a Python data layer, and a TypeScript front end means three ecosystems, three sets of tooling, three ways to be an expert. One language across the stack is a real force multiplier for a small team.
Ignoring the deployment story. A stack isn't just the code — it's how it gets to production. If you can't describe how you'll deploy, monitor, and roll back on day one, you haven't finished choosing.
Confusing TypeScript with optional. For anything non-trivial, type safety pays for itself fast. If you're on the fence, is TypeScript worth it makes the case.

Write the decision down

Whatever you choose, record why in a short document — an architecture decision record, even a single paragraph per major choice. Six months from now, someone will question a call, and "we picked Postgres because we needed transactional integrity and JSON in one database, and we were willing to trade horizontal-scale simplicity for it" is a far better answer than a shrug. Writing it down also forces you to actually have a reason, which catches the choices you were making on vibes.

A stack decision you can defend is a stack decision you can revisit deliberately instead of by accident. Circumstances change — a bet that was right at ten users can be wrong at ten thousand — and the teams that adapt gracefully are the ones who know which assumptions they were betting on in the first place.

We help founders make these calls without the hype every week — if you're staring at a blank architecture diagram, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

Caching strategies for real apps

Doktouri — Wed, 08 Jul 2026 19:40:39 +0000

Caching is the cheapest speed you'll ever buy — and the fastest way to ship subtle, maddening bugs if you do it carelessly. The famous joke that "there are only two hard problems in computer science: cache invalidation and naming things" exists for a reason. Done well, caching cuts latency and load dramatically. Done badly, it serves stale data to users and erodes their trust. Here's how to layer it deliberately.

Cache at the right layer

A request passes through several places where you can cache, each catching a different kind of work:

Client / browser cache. HTTP caching headers (Cache-Control\, ETag\) let the browser skip requests entirely for static assets. Free and enormously effective.
CDN cache. A CDN serves cached responses from the edge, close to users. Ideal for static files and cacheable API responses.
Application cache. An in-memory store like Redis holds computed results, session data, and hot database rows so you don't recompute or refetch them.
Database cache. Query result caching and materialized views cut repeated expensive queries.

The best strategy usually combines several layers. A request that never reaches your server is faster and cheaper than one you serve quickly.

Pick a pattern that matches your data

For application caching, the most common and reliable pattern is cache-aside: on a read, check the cache first; on a miss, load from the database, store it in the cache, then return it. It's simple and puts you in control of what's cached and for how long.

Set a TTL (time to live) on entries so even if invalidation logic has a gap, stale data expires on its own. A short TTL is a safety net — it bounds how wrong the cache can be.

Invalidation is the hard part — plan for it

Stale data is the cost of caching, and the whole craft is managing it. A few tactics that keep you out of trouble:

Prefer expiry over cleverness. A short TTL is often simpler and safer than intricate invalidation logic, and it fails gracefully.
Invalidate on write. When data changes, evict or update the relevant cache key in the same operation.
Namespace and version your keys so you can invalidate a whole category at once and avoid collisions.

Ask a blunt question for each cached value: how wrong can this be, and for how long, before a user is harmed? A product catalog can be seconds stale; an account balance cannot. Let that answer set your TTLs.

Don't cache what you don't need to

Caching adds a moving part, and moving parts break. Before adding a cache, confirm you actually have a hot path worth optimizing — measure first. Sometimes the right fix is an index or a better query, not another layer to keep in sync. Never cache highly personalized or security-sensitive data at a shared layer like a CDN, where one user could receive another's response.

Layer up gradually

Start with the cheap wins: proper HTTP caching headers and a CDN for static assets. Add Redis for genuinely expensive computations and hot data as load grows. Introduce each layer only when you can point to the metric it improves. Caching should be a scalpel you apply to measured bottlenecks — not a blanket you throw over the whole app and hope.

If your app is slow and you're not sure which layer to cache, talk to us.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.

How to build an AI chatbot that's actually useful

Doktouri — Wed, 08 Jul 2026 19:40:05 +0000

Wiring a language model to a chat box takes an afternoon. Building a chatbot people trust and return to takes real engineering. The gap between "it responds" and "it's useful" is where most projects stall — filled with confident wrong answers, lost context, and a bot that cheerfully promises refunds it can't issue. The demo dazzles the stakeholders; the production version has to survive real users asking real, weird questions at 2 a.m. Here's how to cross that gap.

Start with a job, not a technology

Before any code, define the one job the bot exists to do: deflect support tickets, qualify leads, help users navigate a complex product, answer questions over your documentation. A bot with a job can be scoped, measured, and improved. A bot that's just "AI on our site" pleases no one and can't be evaluated because there's no definition of success. Write the job down in a sentence. Everything below serves it.

That sentence also sets your bar for "good enough." A support-deflection bot succeeds if it resolves a meaningful share of tickets and hands off the rest cleanly — it does not need to be right 100% of the time, it needs to know when it isn't. A lead-qualification bot succeeds if it books qualified calls, not if it holds a charming conversation. Defining the job defines the metric, and the metric is what tells you whether to keep tuning or ship. Without it, you'll polish forever and never know if you're done. This is the same discipline that separates a real feature from a demo across AI work generally — the framing in how to integrate AI into your product applies directly.

Ground it or it will make things up

A chatbot answering from the model's general knowledge is a liability the moment users ask about your product, pricing, or policies. It will invent plausible, confidently-wrong answers — and a confident wrong answer is worse than "I don't know," because users act on it. The fix is grounding: retrieve relevant facts from your own content at query time and feed them into the prompt, so answers come from your data, not the model's imagination.

This is retrieval-augmented generation (RAG) applied to conversation — the pattern we unpack for non-engineers in RAG explained for founders. The mechanics:

Chunk your knowledge — docs, help center, policies — into passages of a few hundred tokens, split on meaningful boundaries (sections, not arbitrary character counts).
Embed each chunk into a vector and store it. pgvector on PostgreSQL works well to start and keeps everything in one database; graduate to a dedicated vector database only when scale demands it.
Retrieve the most relevant chunks for each incoming question via similarity search, optionally reranked.
Instruct the model to answer only from the retrieved passages, cite them, and explicitly say when the answer isn't in the provided context.

Retrieval quality is where most RAG bots live or die. If the right chunk never gets retrieved, the best prompt in the world can't save the answer. Invest here: tune chunk size, test your retrieval on real questions, and consider hybrid keyword-plus-vector search for queries full of exact product names or SKUs that pure semantic search fumbles.

Manage context deliberately

Conversations have memory, and memory has limits — both a token budget and an attention budget. You can't stuff an entire chat history into every request: it gets expensive, it's slow, and past a point the model loses focus on what matters. Handle context on purpose:

Keep recent turns verbatim so the immediate thread stays coherent.
Summarize older history into a compact running summary rather than dropping it entirely, so the bot remembers that the user is on the Pro plan and already tried restarting.
Re-retrieve per turn. Fetch fresh grounding for the current question, not just the first one — conversations drift, and stale context produces answers to a question the user already moved past.

Put guardrails around it

A production bot needs boundaries, both to stay safe and to stay on-topic:

Scope it. A system prompt that defines what the bot does — and refuses politely outside it — prevents your support bot from writing poetry, giving medical advice, or being talked into your competitor's marketing.
Validate actions. If the bot can do things (create a ticket, issue a refund, change a subscription), gate those behind explicit confirmation and server-side authorization checks. Never let raw model output directly trigger a sensitive operation. Treat the model as an untrusted user that proposes actions your backend independently verifies against the real user's permissions.
Defend against prompt injection. Retrieved content and user messages can contain instructions that try to hijack the bot ("ignore previous instructions and..."). Keep system instructions and untrusted content clearly separated, never grant the model more authority than the user it's acting for, and screen inputs and outputs. This overlaps with ordinary application security — the basics in how to secure your web app still apply.

Choose the model deliberately — and keep the seam

Bigger isn't always better. Use a capable model for the hard reasoning turns, but route simple classification or routing steps to a smaller, cheaper, faster one. A frontier model on every keystroke will make the unit economics ugly at scale, and latency is part of the product — a bot that takes eight seconds to reply feels broken no matter how good the answer. Streaming responses token-by-token helps perceived speed enormously.

Because models and prices change every few months, wrap the whole thing in a thin, typed TypeScript service with a clean model-agnostic interface. That seam lets you swap providers, tune prompts, and adjust retrieval without touching the front end — and lets you A/B a cheaper model against your current one. On managing that bill as usage grows, see LLM cost optimization.

Decide: chatbot or workflow?

Not every "AI feature" should be a free-form chat. If the task is a fixed sequence — collect three fields, look something up, take one action — a structured agent or workflow is more reliable, cheaper, and easier to test than an open conversation. Reach for a chatbot when the interaction is genuinely open-ended. Using a chat interface for what's really a form frustrates users and multiplies your failure modes.

A reference architecture

Pulling it together, a production chatbot is more moving parts than the chat box suggests. A workable shape:

Ingestion pipeline — a job that chunks your source content, embeds it, and upserts it into the vector store, re-running whenever the source changes so the bot never answers from stale docs.
Retrieval layer — takes the user's message plus recent context, runs the similarity (and ideally keyword) search, and returns the top passages with their source links.
Orchestration service — the typed TypeScript seam that assembles the prompt (system instructions + retrieved context + trimmed history), calls the model, streams the response, and enforces the guardrails.
Action layer — a small, explicit set of server-side functions the model may propose calling, each re-checking authorization before it runs.
Observability — logging, the evaluation test set, and the quality signal wired in from day one, not bolted on after launch.

None of these is exotic, but skipping any one is how a demo fails to become a product. The retrieval and observability layers are the ones teams most often shortcut, and the ones that most determine whether the bot is actually trusted.

Design the escape hatch

The single most trust-building feature of any chatbot is a graceful handoff. When the bot is unsure, when it's failed twice, or when the user is clearly frustrated, it should offer a human, a form, or a clear next step — not loop endlessly apologizing. A bot that knows its limits and hands off cleanly feels far more competent than one that fakes confidence to the bitter end. Detect frustration and repeated failure explicitly, and make the exit obvious.

Build the evaluation loop

You cannot improve a chatbot by vibes, and "it seemed fine when I tried it" is how bad bots ship. Set up a habit of measurement before you launch, not after:

A test set of real questions with known-good answers, run automatically on every prompt, model, or retrieval change so you catch regressions before users do. This is the closest thing RAG has to unit tests.
Logging of real conversations (respecting privacy and consent) so you see where it actually fails in the wild — the failures you didn't imagine are the ones that matter.
A quality signal — thumbs up/down, a resolution flag, or whether the conversation ended in a handoff — so you can track quality as a number over time rather than a feeling.

Then close the loop: mine the failures, fix the retrieval gaps or prompt holes they reveal, and re-run the test set. That iteration cadence, not any single clever prompt, is what turns a mediocre bot into a good one.

A useful chatbot is scoped to a real job, grounded in your data, careful with context, guarded against misuse, honest about uncertainty, and continuously evaluated. Skip those and you have a demo that impresses in the meeting and disappoints in production. If you want to build one that actually earns its place in your product, let's talk.

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.