DEV Community: Pykero

When to Ask for Push Notification Permission (And When Not To)

Pykero — Thu, 09 Jul 2026 09:31:57 +0000

Most apps ask for push notification permission on the first screen the user sees, before they've done anything worth being notified about. On iOS, that single dialog is a one-shot deal — decline it and the only way back is a trip to Settings that almost nobody makes. We've watched opt-in rates on client apps swing from under 30% to over 70% by changing nothing except when the OS prompt fires. The copy, the icon, the app itself stayed the same.

If you're building or rebuilding a mobile app's onboarding flow, permission timing deserves as much design attention as the signup form.

Why the native prompt is a one-shot resource

iOS shows the system permission dialog exactly once per app install. There's no "ask again later" — if the user taps Don't Allow, your only path back is Linking.openSettings()\ and a user willing to dig through iOS Settings > Notifications > Your App. Android has historically been more forgiving (pre-13, permission was implicit; 13+ requires an explicit runtime request, but re-prompting is still possible under some conditions), which means teams that build permission flows against Android behavior first often get burned when they ship to iOS.

Treat the native prompt as a resource you spend once. Everything before it should exist to make that one shot count.

The soft-ask pattern

The fix is a pre-permission screen you control entirely — a normal in-app UI element, not a system dialog — that explains the value of notifications before the OS prompt appears:

"Get notified when your order ships" with a bell icon and two buttons, Enable Notifications and Not Now
Only tapping Enable Notifications triggers the real OS permission request
Tapping Not Now dismisses without touching the OS-level state at all, so the real prompt is still available later

This matters because a soft-ask rejection costs nothing — you can show it again next session, after a different action, with different copy. A hard-ask (OS) rejection on iOS is close to permanent.

\`tsx
import * as Notifications from 'expo-notifications';

async function requestPushPermission() {
const { status: existing } = await Notifications.getPermissionsAsync();
if (existing === 'granted') return true;

const { status } = await Notifications.requestPermissionsAsync();
return status === 'granted';
}

// Only call requestPushPermission() after the user taps
// "Enable Notifications" on your own in-app screen.
`\

Timing: contextual beats chronological

"Day 3" or "after onboarding" is chronological timing — it's easy to implement and it's why most apps still ask at launch, on a fixed step. Contextual timing ties the ask to a moment where the value is obvious:

E-commerce: after the first order is placed, not before ("track your delivery")
SaaS/dashboard apps: after the user creates the first thing worth monitoring (a project, an alert, a report)
Social/messaging: after the first message is sent or received, not on account creation
Booking/scheduling: right after a booking is confirmed ("we'll remind you before it starts")

If your app doesn't have an obvious "moment," don't fabricate one — a generic ask on session 2 or 3 still outperforms session 1, because the user has at least formed a first impression of the product.

Platform differences that break naive implementations

iOS: one shot per install (until the user manually deletes and reinstalls the app, which resets permission state). Provisional authorization (provisional: true\ in the request options) delivers notifications quietly to Notification Center without a prompt at all — useful for low-stakes, high-volume notification types where you'd rather earn trust than ask upfront.
Android 13+: POST_NOTIFICATIONS\ is a runtime permission like camera or location, requested the same way. Below Android 13, notifications are granted by default at install, so testing only on newer Android devices can hide bugs that show up for a real chunk of your Android install base.
Background/foreground state: some permission APIs behave differently depending on whether the request happens immediately on mount vs. after a useEffect\ delay — test the actual timing you'll ship, not just the API call in isolation.

This is one of the areas where React Native vs. Flutter matters less than people expect — both wrap the same underlying OS permission model, and both will burn you the same way if you ask too early.

Instrument it before you optimize it

You cannot tune permission timing without data. Track, at minimum:

Soft-ask shown → Soft-ask accepted (your in-app funnel)
Soft-ask accepted → OS permission granted (how much the OS prompt itself costs you)
Time-to-first-notification-received (a proxy for whether the notification is actually useful once granted)

Without these events split out, "opt-in rate" as a single number hides whether the drop-off is your copy, your timing, or the OS prompt itself — three very different fixes.

A simple checklist

Never trigger the OS permission dialog on first launch or from a generic onboarding step
Build a soft-ask screen you fully control, with copy tied to a concrete benefit
Trigger the soft-ask after a contextual action, not a fixed day/step count
Handle iOS's one-shot behavior explicitly — treat rejection as (near) final, and offer a Settings deep link post-decline instead of re-asking
Test on Android 13+ devices specifically; don't assume pre-13 behavior generalizes
Instrument each funnel step separately before changing anything

This kind of detail is easy to skip when you're racing toward a launch date, but it's cheap to build correctly the first time and expensive to retrofit once your install base has already seen — and declined — the wrong prompt. If you're scoping a new mobile build or auditing an existing one's performance and onboarding, let's talk.

Originally published on the Doktouri Agency blog.

How to work with a software agency

Pykero — Thu, 09 Jul 2026 01:30:23 +0000

A good software agency can move faster than most companies could hire for, but the outcome depends as much on how you work with them as on how good they are. The same team produces a great product for one client and a frustrating one for another. The difference is usually the client's side of the relationship: the brief, the cadence, and how decisions get made. Here's how to be the client that gets great work.

Brief the problem, not the solution

The most useful thing you can hand an agency is a clear problem, the users it affects, and the outcome you need — not a pre-baked feature list. A good team will pressure-test your assumptions and often find a simpler path to the same goal. If you hand over only a spec to implement, you've bought hands, not expertise, and left the best part on the table.

Bring context: who the users are, what success looks like, what constraints are non-negotiable, and what you've already tried.

Name one decision-maker

Projects stall when the agency can't get a clear answer. Designate a single person on your side who can make decisions and unblock questions quickly. Feedback by committee — five stakeholders with contradictory notes — is one of the surest ways to slow a project and blow a budget.

That person doesn't need to know how to code. They need to be reachable and able to decide.

Agree the cadence up front

Set the rhythm before the work starts:

A regular check-in — weekly is a sane default — with working software, not slides.
A shared channel for quick questions so small blockers don't wait days.
A visible backlog or board so you always know what's in progress and what's next.
A clear escalation path for when something's off track.

Steady cadence beats long silences punctuated by big reveals. You want to catch a wrong turn in week two, not month two.

Give feedback on outcomes

The most useful feedback describes the problem, not the fix. "Users won't understand this step" is far more actionable than "make the button green." Trust the team on implementation while holding them firmly to outcomes — that's the division of labor that actually works.

Expect trade-offs, not magic

Scope, time, and cost trade against each other; no team escapes that. A partner worth keeping will tell you when something will take longer or cost more, and offer options. Treat that honesty as a feature. The agency that says yes to everything without flinching is the one to worry about.

Red flags to watch for

No questions about your users or business — just eagerness to start coding.
Estimates with no ranges and no assumptions stated.
Reluctance to show work until it's "done."
Communication that goes quiet for stretches.

Any one of these early is worth raising before it compounds.

At Doktouri we work as a partner, not a vending machine — we question the brief, ship on a steady cadence, and tell you the trade-offs straight. If you're looking for an engineering partner, talk to us.

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

Agency vs in-house team

Pykero — Thu, 09 Jul 2026 01:29:49 +0000

"Should we hire an agency or build a team?" is really four questions wearing one coat: how fast do you need to move, how much will it cost, how much control do you want, and where should the knowledge live? The honest answer is that it changes with your stage — and often the smartest move is a mix. Here's how to reason about it instead of defaulting to whichever feels safer.

Speed: the agency's clearest edge

An established agency can start next week with a team that has already worked together. Hiring in-house — sourcing, interviewing, onboarding, waiting out notice periods — realistically takes months before anyone ships. When time to market is the binding constraint, that gap is decisive. Agencies win on speed almost every time.

Cost: cheaper up front, different long-term

An agency's hourly or project rate looks expensive next to a salary. But a salary is the smallest part of an employee's true cost — benefits, equipment, management, and the risk of a bad hire all stack on top, and you pay whether or not there's work to do.

For bursty or finite work, an agency is usually cheaper because you pay only for what you need. For steady, indefinite work, an in-house team eventually becomes the better economics. The crossover is roughly whether the work is a project or a permanent function.

Control and context

In-house teams live inside your business. They absorb context in hallway conversations, feel the mission, and are always available for the quick question. An agency, however embedded, is one step removed and shared with other clients.

If the work demands deep, constantly-evolving domain knowledge, in-house has a real edge. If it's a well-defined build, that gap matters far less than it feels like it should.

Knowledge retention: the real long-term risk

The strongest argument for in-house is that the knowledge stays. When an agency finishes, its understanding of your system can walk out with it. Mitigate that regardless of who builds:

Insist on documentation as a deliverable, not a favor.
Own your repositories, infrastructure, and accounts from day one.
Have your people involved enough to maintain what's built.

An agency that resists any of these is a warning sign.

Match the model to the stage

Early / pre-product-market-fit — an agency gets you to a testable product fast, before you know which skills to hire permanently.
Scaling a validated product — start building in-house for the core, where retained knowledge compounds.
Spikes and specialties — use an agency for finite projects or skills you don't need full-time, even with a strong internal team.

The hybrid most teams land on

In practice the answer is rarely pure. A common, effective pattern: a small in-house core owns the product and domain, an agency provides velocity and specialized skills, and ownership of code and infrastructure stays firmly with you. You get speed without hollowing out your own capability.

At Doktouri we work both as a standalone team and as an extension of an in-house one, and we'll tell you honestly which your stage calls for. If you're weighing the decision, talk to us.

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

Web accessibility basics every team should ship

Pykero — Thu, 09 Jul 2026 01:24:09 +0000

Accessibility gets treated as a specialist compliance topic, which scares teams into doing nothing. The truth is that a handful of fundamentals cover the vast majority of real-world needs, they're cheap to build in from the start, and they make the product better for everyone — not just users with disabilities. Here's the baseline every team should ship, in priority order.

Start with semantic HTML

The single highest-leverage accessibility decision is using the right HTML element for the job. A <button>\ is focusable, keyboard-operable, and announced correctly by screen readers for free. A <div>\ with a click handler is none of those things.

Use <button>\ for actions, <a>\ for navigation — never a styled <div>\
Use headings (<h1>\–<h6>\) in order to convey structure
Use <nav>\, <main>\, <header>\, and <footer>\ landmarks
Use real <label>\ elements tied to their inputs

Get this right and you've solved most accessibility problems before writing a line of ARIA.

Make everything keyboard-operable

Many users navigate entirely by keyboard. Tab through your whole app and check two things: can you reach and activate every interactive element, and can you always see where focus is? A visible focus ring is not optional — never remove the outline without replacing it with something clearer.

Watch for keyboard traps (focus that gets stuck in a modal), custom dropdowns that ignore arrow keys, and click handlers on non-focusable elements.

Get contrast and text right

Low-contrast text is the most common accessibility failure and it's trivial to fix. Aim for a contrast ratio of at least 4.5:1 for body text and 3:1 for large text. Don't rely on color alone to convey meaning — an error state needs an icon or text, not just red.

Let users zoom and resize text without breaking the layout, and never disable pinch-to-zoom on mobile.

Handle images and dynamic content

Give informative images meaningful alt\ text; give decorative images empty alt=""\ so screen readers skip them
Announce dynamic updates (toasts, live validation) with an aria-live\ region so screen reader users hear them
Ensure modals trap and return focus correctly

Use ARIA sparingly and correctly

ARIA lets you patch accessibility onto custom widgets, but the first rule of ARIA is: don't use it if native HTML can do the job. Bad ARIA is worse than none — a wrong role\ actively misleads assistive technology. Reserve it for genuinely custom components (tabs, comboboxes, custom dialogs) and follow the established patterns rather than improvising.

Bake it into the workflow

Accessibility fails when it's a pre-launch audit instead of a habit. Cheap ways to keep it healthy:

Run an automated linter (axe, eslint-plugin-jsx-a11y) in CI to catch obvious regressions
Tab through new features before merging
Test occasionally with an actual screen reader (VoiceOver, NVDA)

Automated tools catch maybe half of issues, so the manual checks matter. But this baseline — semantic HTML, keyboard access, contrast, and honest ARIA — clears most of the bar and rarely costs extra time when built in from day one.

If you need an existing product audited against WCAG or want accessibility built into a new build from the start, let's talk.

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

Vector databases explained

Pykero — Thu, 09 Jul 2026 01:23:36 +0000

Behind almost every "AI-powered search" and RAG feature sits the same quiet workhorse: similarity search over vectors. If you're building anything that finds relevant content by meaning rather than exact keywords, you need to understand vectors — and, importantly, when you do and don't need a dedicated database for them.

From text to vectors

An embedding is a list of numbers — a vector — that captures the meaning of a piece of text (or an image, or audio). An embedding model turns "cancel my subscription" and "how do I stop being billed" into vectors that sit close together, even though they share almost no words.

That closeness is the whole trick. Meaning becomes geometry: similar concepts land near each other in a high-dimensional space, and "find related content" becomes "find nearby vectors."

How similarity search works

Once your content is stored as vectors, retrieval is straightforward in principle:

Embed the user's query into a vector.
Find the stored vectors closest to it — typically by cosine similarity.
Return the content those nearest vectors belong to.

The challenge is doing step 2 fast when you have millions of vectors. Comparing against every one is too slow, so vector indexes use approximate nearest neighbor (ANN) algorithms that trade a tiny bit of accuracy for enormous speed.

Do you actually need a vector database?

This is the question that matters, and the honest answer is: usually not at first.

If you already run PostgreSQL — and with Supabase you do — the pgvector extension adds vector columns and ANN indexing right inside your existing database. That means:

One system to operate, back up, and secure, not two.
Joins between your vectors and your regular relational data in a single query — filter by tenant, date, or category and similarity together.
No extra service to sync, pay for, or keep consistent.

For most products up to millions of vectors, pgvector is not a compromise — it's the pragmatic right answer.

When a dedicated vector database earns its place

Graduate to a specialized vector store when you hit real limits:

Very large scale — tens or hundreds of millions of vectors where purpose-built indexing and sharding matter.
High query throughput that would compete with your transactional workload.
Advanced retrieval features like sophisticated hybrid search or filtering that a dedicated engine handles better.

Even then, keep the metadata your app relies on in Postgres; let the vector store do only what it's uniquely good at.

Getting retrieval quality right

The database is rarely the hard part — retrieval quality is. A few things move it more than your choice of engine:

Match your embedding model to your domain, and use the same model for indexing and querying.
Combine vector search with keyword search (hybrid) so exact terms like product names still land.
Filter before or alongside similarity so results respect tenancy and permissions.
Re-rank the top candidates to push the best context to the front.

Start simple with pgvector, measure retrieval quality on real queries, and scale the infrastructure only when the numbers demand it. If you're building AI search or RAG and want it fast and accurate without over-engineering the stack, talk to us.

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

Is TypeScript worth it?

Pykero — Thu, 09 Jul 2026 01:17:56 +0000

Here's the straight answer: for anything beyond a throwaway script or a tiny prototype, TypeScript is worth it. The costs are real but front-loaded and shrinking; the payoffs compound as the codebase and team grow. The interesting question isn't whether to use it — it's understanding exactly what you're buying and what you're paying, so you adopt it with your eyes open.

What you're actually buying

TypeScript's value isn't just "catching bugs," though it does that. The bigger wins are structural:

Refactoring confidence. Rename a function or change a data shape and the compiler shows you every place that breaks. On a large codebase, this turns terrifying changes into routine ones.
Self-documenting code. Types are documentation that can't go stale. A function signature tells you what goes in and comes out without reading the body.
Editor superpowers. Real autocomplete, inline errors, and go-to-definition that actually knows your data. This alone speeds up daily work.
Fewer whole classes of bugs. Undefined-is-not-a-function, wrong argument order, typo'd property names — gone at compile time instead of in production.

These benefits grow with codebase size and team count. They're modest on a solo weekend project and enormous on a product several engineers maintain for years.

What you're paying

Be honest about the costs:

A learning curve — generics, utility types, and gnarly library types take time to get comfortable with.
Some upfront friction — you write type annotations and occasionally fight the compiler over code you "know" is fine.
Build tooling — a compile step and configuration, though modern tools have made this nearly frictionless.
Type gymnastics temptation — teams sometimes over-engineer types into unreadable puzzles. Discipline matters; simple types are usually the right ones.

Notably, these costs are heaviest at the start and drop sharply as fluency grows. The tax you pay in week one isn't the tax you pay in month six.

Adopt it incrementally

You don't need a big-bang rewrite. TypeScript is designed for gradual adoption:

Turn it on with loose settings and allowJs\, so JavaScript and TypeScript coexist
Convert files as you touch them, starting with core data models and shared utilities where types pay off most
Tighten tsconfig\ over time — enable strict\ once you're ready; it's where most of the safety lives
Use unknown\ over any\ at boundaries, and reserve any\ as a deliberate, rare escape hatch

This lets a team get value immediately without halting delivery.

Where it matters most — and least

Use TypeScript for: production apps, anything a team maintains, shared libraries, and long-lived codebases. That's almost everything real.

Skip it (or don't bother) for: genuine one-off scripts, quick throwaway prototypes, and tiny snippets where the ceremony outweighs the payoff.

The bottom line

For serious software, the question is settled — TypeScript's compounding benefits to safety, refactoring, and developer experience clearly outweigh its front-loaded costs. The teams that regret it almost always over-complicated their types; the fix is discipline, not abandonment. Adopt it gradually, keep types simple, and enable strict mode when you're ready.

If you're weighing a TypeScript migration on an existing JavaScript codebase and want a low-risk incremental plan, talk to us.

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

Managing technical debt without halting delivery

Pykero — Thu, 09 Jul 2026 01:17:23 +0000

Technical debt gets talked about like moral failure — sloppy work someone should feel bad about. That framing is wrong and it leads to bad decisions. Debt is a tool: sometimes you deliberately take a shortcut to hit a deadline or test an idea, and that's a rational trade. The problem isn't taking on debt; it's taking it on blindly and never paying interest. The goal isn't zero debt — it's managed debt.

Not all debt is equal

The financial metaphor is genuinely useful. Some debt is a smart, low-interest loan; some is a payday loan strangling your velocity. Sort it honestly:

Deliberate and prudent: "We'll hardcode this now and generalize it when we have a second use case." Fine.
Deliberate and reckless: "We don't have time to test any of this." Dangerous.
Accidental: design decisions that only looked wrong once the product evolved. Inevitable and normal.

What matters is the interest rate — how much a given piece of debt slows you down every single week. High-interest debt in a hot path is worth paying down now; low-interest debt in a stable corner nobody touches can sit forever.

Make it visible

Debt you can't see, you can't manage. The most common failure is that it lives only in senior engineers' heads as vague dread. Instead:

Write it down. File tickets for known debt with a note on the pain it causes and where.
Leave signposts in code. A consistent // TODO\ or // DEBT\ convention you can grep for turns tribal knowledge into a searchable list.
Watch the signals. Rising bug rates in one module, slowing delivery, or the same area breaking repeatedly all point to where debt is compounding.

Making debt legible turns anxious hallway conversations into a prioritized, decidable list.

Pay it down continuously, not in a big bang

The instinct to stop all feature work for a "refactoring sprint" almost always backfires — the business resents it, and a giant rewrite is its own risk. Continuous, incremental repayment works far better:

Budget a slice of every cycle — say 15 to 20 percent — for debt and maintenance. Predictable and sustainable.
Use the boy-scout rule: leave code a little cleaner than you found it whenever you touch it for a feature.
Pay down debt where you're already working. Refactoring the module you're about to extend is cheap; refactoring a random quiet one is speculative.

This keeps the codebase healthy without ever fully stopping delivery, which is the whole point.

Tie it to business outcomes

The reason "we need to refactor" falls on deaf ears is that it's framed as engineering hygiene. Translate it into the language stakeholders act on: this debt is why the last three features each took a week longer than estimated, or this is why we get paged every weekend. When you connect debt to shipped velocity, reliability, and cost, prioritizing it stops being a fight.

The balance

Managing technical debt is a continuous act of judgment, not a cleanup project you finish. Take it on deliberately, track it openly, pay it down where the interest is highest, and never let it become invisible. A team that does this ships fast and keeps a codebase they can still move in a year from now — you don't have to choose.

If your delivery is slowing and debt is the suspect, talk to us.

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

Supabase vs Firebase

Pykero — Thu, 09 Jul 2026 01:11:43 +0000

Both Supabase and Firebase promise the same thing: a backend you don't have to build, with auth, a database, storage, and real-time out of the box. They get you to a working app astonishingly fast, which is why they dominate the "backend-as-a-service" conversation. But under the hood they make very different bets, and the one you pick shapes how your product evolves for years. Here's how we decide.

The core difference: relational vs document

Everything else follows from this. Firebase's Firestore is a NoSQL document store. Data lives in nested collections of documents, and you model it around the exact queries your screens make. That's liberating early on and painful later — anything relational (joins, aggregates, reporting, "show me all X where related Y is Z") requires denormalization, fan-out writes, and careful bookkeeping to keep duplicated data consistent. You essentially trade write simplicity and query flexibility for read speed on pre-shaped access patterns.

Supabase is PostgreSQL with a well-built platform wrapped around it. You get a real relational schema, SQL, foreign keys, joins, transactions, and every Postgres feature — JSON columns, full-text search, pgvector\ for AI embeddings, materialized views — from day one. For most business software, which is inherently relational, this is the more durable foundation. Our deeper take on why lives in PostgreSQL for startups.

The honest version: if your data is genuinely document-shaped and query patterns are simple and known in advance, Firestore is a fine fit. The moment you need reporting, ad-hoc queries, or complex relationships — and most products eventually do — Postgres wins decisively.

Lock-in and portability

This is the quiet dealbreaker for a lot of teams, and it deserves more weight than it usually gets. Firebase is proprietary and Google-hosted; there is no Firestore outside Google. Migrating off it means rewriting your entire data layer against a different database, because nothing else speaks Firestore's model or API.

Supabase is open source and just Postgres underneath. You can pg_dump\ your database and move it to any Postgres host on earth — AWS RDS, a droplet, your own hardware — self-host the entire Supabase platform, or point existing SQL tooling straight at it. Your data isn't hostage to one vendor's roadmap or pricing. If avoiding vendor lock-in matters to you at all, Supabase's answer is simply stronger, and it's not close.

Real-time and auth

Both handle the common cases well, with different characters:

Real-time: Firestore's live listeners are mature, battle-tested, and deeply integrated — this was a first-class feature from day one. Supabase streams Postgres changes over websockets, which is excellent for typical collaborative and live-update workloads, though very high-frequency, high-fan-out cases need more thought and tuning.
Auth: Both give you email, OAuth providers, and session management within minutes. The differentiator is that Supabase pairs auth with row-level security in Postgres, so your access rules live in the database itself as declarative policies — a clean, auditable, single-source-of-truth model. Firebase uses a separate security-rules language layered on top of Firestore, which works but lives apart from your data.

Offline and mobile SDKs

One area where Firebase still leads: mature, first-party mobile SDKs with robust offline persistence and sync built in. If you're shipping a mobile app that must work fully offline and reconcile automatically when it reconnects, Firebase's offline story is more turnkey today. Supabase's mobile support is solid and improving, but offline-first sync is something you'll assemble more deliberately. If mobile-offline is a hard requirement right now, weigh this seriously — and see React Native vs Flutter for the client side of that decision.

Pricing and scaling behavior

Firebase's per-operation pricing (billed per document read, write, and delete) is friendly at tiny scale but can surprise you as usage climbs — a poorly-shaped query that reads thousands of documents, or a chatty real-time screen, translates directly into a bill that's genuinely hard to predict. Supabase bills closer to compute and storage on predictable tiers, which tends to be more legible as you grow because it doesn't scale linearly with every read. Neither is universally cheaper — model your actual read/write pattern before committing, because the shape of your access dictates which one is affordable.

On scaling, Firestore autoscales seamlessly and effectively infinitely, but it does so by constraining how you're allowed to query — you cannot write an expensive query, because the model won't let you. Postgres gives you full query power with the classic trade-off that you'll eventually tune indexes, add read replicas, and manage connection pooling yourself (or lean on Supabase's managed layer, connection pooler, and read replicas to soften that).

Developer experience and the shape of your day

The two platforms feel different to work in, and that texture matters over months of building. With Supabase, you're working with SQL and a relational schema, which means you can use the entire universe of Postgres knowledge, tooling, and Stack Overflow answers accumulated over decades. Migrations are versioned SQL files, the dashboard gives you a real table editor and SQL runner, and the auto-generated APIs and TypeScript types keep the client in sync with your schema. If your team knows databases, they'll feel at home immediately.

With Firebase, you think in documents and collections, and you shape your data around access patterns rather than normalized truth. The tooling is polished and the SDKs are excellent, but you're learning Google's model and its security-rules language, and denormalization becomes a discipline you maintain by hand. It's fast to start and can feel magical for simple apps; the friction shows up later, when a reporting requirement or a new relationship forces you to reshape data that's already duplicated across the store.

A migration reality check

Teams often ask "can I switch later?" The honest answer shapes the decision. Moving to Supabase from a relational-shaped Firestore is doable but real work — you're mapping documents into tables, reconstructing relationships that were implicit, and rewriting the data layer. Moving off Firebase is harder the longer you wait, because more of your app assumes its model and API. Postgres, being an open standard, is the easier thing to leave: any host, any tool, a plain pg_dump\ away. That asymmetry is itself an argument — starting on the more portable foundation keeps your future options open, which is exactly the lens we bring to choosing a tech stack.

When to choose Supabase

Your data is relational — which most business and SaaS data is.
You need reporting, analytics, ad-hoc queries, or complex relationships.
Avoiding vendor lock-in and keeping data portable matters.
You want AI/vector search (pgvector\) alongside your primary data.
Your team already knows SQL and wants its full power.

When to choose Firebase

Your data is genuinely document-shaped with simple, known query patterns.
You're already deep in the Google Cloud ecosystem.
You need best-in-class mobile SDKs with offline sync today.
You want maximum autoscaling with zero query tuning.

Common mistakes teams make

The decisions people regret tend to share a root cause — optimizing for the first week instead of the next three years:

Choosing Firestore for clearly relational data because it felt faster to start, then hitting a wall the moment reporting, joins, or analytics show up on the roadmap.
Ignoring the pricing model until the bill arrives — building read-heavy, chatty screens on Firestore's per-operation pricing and being surprised when usage scales the cost linearly.
Underestimating lock-in until a re-platform, an acquisition, or a compliance requirement forces a migration that a proprietary store makes genuinely painful.
Reaching for Supabase but never using Postgres — treating it as a document store and missing the relational power, row-level security, and pgvector\ that were the whole point.

Pick based on the true shape of your data and where the product is heading, not on which quickstart felt smoothest.

The verdict

Our default for SaaS is Supabase, and the reasoning compounds: relational data, real reporting, row-level security, pgvector\, and no lock-in add up to a foundation you won't outgrow. Firebase remains a legitimate, faster on-ramp when your data is document-shaped, you live in Google's ecosystem, or you need turnkey mobile offline sync right now.

If you're genuinely unsure, choose the relational option. It is far easier to ignore Postgres features you don't need yet than to bolt relationships, joins, and reporting onto a document store after the fact. This is the same principle we apply when choosing a tech stack generally — pick the foundation that keeps the most doors open.

One more thing worth saying plainly: the fast start is a trap if it points you at the wrong foundation. Both tools get you a working app in an afternoon, so speed-to-first-screen is a poor tiebreaker — they're roughly equal there. Judge them instead on the thing you'll actually live with, which is how your data model holds up as the product grows more complex, more relational, and more demanding of reporting. That question has a clear answer for most business software, and it's why we default to the relational side.

Either way, treat the backend as a foundation you'll build on for years, not a demo shortcut. If you want help matching one to your product's real data shape, let's talk.

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

Software project red flags to watch for

Pykero — Thu, 09 Jul 2026 01:11:09 +0000

Software projects rarely fail all at once. They fail slowly, through warning signs that were visible weeks before the missed deadline made it official. The good news is that these signals are consistent across projects — once you know them, you can spot trouble while it's still cheap to fix. Here are ten to watch for, and what to do about each.

1. You haven't seen working software in weeks

The single most reliable warning sign. If progress is only ever described in status updates and slides, you don't actually know where things stand. Insist on running software at a regular cadence. "Almost done" with nothing to click is the phrase that precedes most overruns.

2. Nobody can state what "done" means

If the team and the stakeholders would describe the finished product differently, the project is built on sand. Stop and write down a shared definition of done before more code accumulates on a shaky foundation.

3. Estimates have no ranges or assumptions

A confident single-number estimate with no stated assumptions isn't precision — it's a guess in a suit. Real estimates carry ranges and list what they depend on. Their absence means the uncertainty is hidden, not gone.

4. Scope grows but the timeline doesn't

Every project changes. The red flag is changes being absorbed silently while the deadline stays fixed. Without visible change control, you're accumulating a debt that comes due all at once near the end.

5. One person is the only one who understands a critical part

Key-person risk. If a single developer holds knowledge nobody else has, illness, distraction, or departure can stall the whole project. Push for documentation and shared ownership before that bus factor bites.

6. Communication has gone quiet

Healthy projects are noisy — questions, demos, small course-corrections. A stretch of silence usually means someone is stuck and not saying so. Quiet is rarely a sign that everything's fine.

7. Testing is "something we'll do at the end"

Deferring all testing to the end guarantees a crunch and hides risk until it's most expensive. Quality checks should run continuously, not pile up behind a launch date.

8. Every feature is "critical"

If nothing can be cut, no one has made a real priority call. A project with no cut list has no plan for when time runs short — and time always runs short. Force a ranking.

9. The team stopped asking questions

Early on, a good team interrogates the problem. If the questions dried up, either everything is genuinely clear (rare) or people have stopped engaging and are heads-down building the wrong thing.

10. Bad news only travels upward late

The most dangerous culture is one where problems are hidden until they're unavoidable. You want the team surfacing risks early, while there's still room to react. If you only hear about slips at the deadline, the reporting itself is broken.

What to do when you spot one

One flag is a conversation. Several together is a pattern that needs intervention — re-establish cadence, rewrite the definition of done, and force the priority calls that got skipped. The earlier you act, the cheaper the fix.

At Doktouri we run projects to keep these flags from appearing — working software on a cadence, honest estimates, and early bad news. If a project of yours is showing warning signs, let's talk.

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

Server-side rendering and SEO

Pykero — Thu, 09 Jul 2026 01:05:30 +0000

Your content can be brilliant, but if a search crawler receives a blank HTML shell and a bundle of JavaScript, none of it counts. Rendering strategy — where and when your HTML gets built — quietly decides whether Google sees a finished page or an empty stage. For anything that depends on organic traffic, this is the SEO decision that comes before keywords, links, or content. You can do everything else right and still be invisible if the crawler never sees your words.

The three rendering strategies

CSR (client-side rendering): the server sends a near-empty HTML file plus a JavaScript bundle. The browser downloads, parses, and executes that JavaScript, which then builds the page. Fast to develop and cheap to host, but the initial HTML — the thing a crawler reads first — is essentially blank.
SSR (server-side rendering): the server runs your application code and builds full HTML for each request, sending it ready to display. The browser paints it immediately, then "hydrates" it — attaching JavaScript to make it interactive.
SSG (static site generation): pages are rendered to HTML once, at build time, and served as static files from a CDN. Fastest of all and nearly bulletproof to serve, but content is frozen until the next build and redeploy.

The distinction that matters for SEO is simple: SSR and SSG both hand crawlers complete HTML on the first request. CSR does not. With CSR, the meaningful content only exists after JavaScript runs — and whether that happens reliably, for every crawler, on every page, is out of your hands. That single fact is the root of every problem below. Everything else in this article is a consequence of it.

Why CSR hurts SEO in practice

Google can execute JavaScript, so people assume CSR is fine. In reality it's fragile, and the fragility is the whole problem. Google's indexing happens in two waves: it crawls the raw HTML first, then queues the page for a second, deferred rendering pass where JavaScript actually runs. That second pass can be delayed by days when crawl budget is tight, and if your content only exists after JS executes, it isn't indexed until — and unless — that pass completes.

And Google is the best-case crawler. The wider ecosystem is worse: many social preview bots (the ones that generate the card when someone shares your link), a number of AI crawlers, and Bing in various configurations handle JavaScript poorly or not at all. They see the blank shell and move on.

That fragility shows up as concrete, revenue-affecting symptoms:

Delayed or inconsistent indexing of new pages — you publish, and nothing appears in search for weeks
Missing or broken social previews when links are shared, tanking click-through
Meta tags, canonical URLs, and structured data that never get read because they're injected by JavaScript
Content that quietly ranks below server-rendered competitors who gave the crawler an easier job

When your rank — and the traffic that pays your bills — depends on it, "usually works" is not a strategy. This is precisely why we lean toward frameworks with first-class server rendering; it's part of the calculus in Next.js vs React and in how to choose a tech stack.

Choosing SSR vs SSG

Both are SEO-friendly — the crawler gets real HTML either way. Pick between them based on how often the content changes and whether it's personalized:

SSG for content that's stable between deploys — marketing pages, landing pages, documentation, most blog posts (like this one). It's the fastest and cheapest to serve, scales infinitely from a CDN, and has almost no attack surface.
SSR for content that's personalized or changes constantly — product pages with live inventory and pricing, search and filter results, anything user-specific with a public URL. You pay for a server render on every request, but the content is always fresh.
ISR (incremental static regeneration), offered by frameworks like Next.js, blends the two: serve fast static HTML, but regenerate individual pages in the background on a schedule or on-demand when the data changes. This is the sweet spot for large content sites and e-commerce catalogs — thousands of pages that update periodically but don't need per-request rendering.

You don't have to pick one strategy for the whole site. The best setup usually mixes all three, chosen per route: static marketing pages, ISR for the product catalog, SSR for search.

It's about more than crawlers

Server rendering also improves the metrics real users feel — and that Google now measures directly. HTML that arrives ready to display produces a faster Largest Contentful Paint and far less layout shift than a page assembled from scratch in the browser after a JavaScript download. Users on slow phones and flaky networks — a large share of the web — feel this most, and they're the ones most likely to bounce from a blank screen.

Since Core Web Vitals are a ranking signal, SSR and SSG help you twice: crawlers see your content, and users get a measurably faster page, which lifts both rankings and conversion. The two goals point the same direction. Our Core Web Vitals guide covers how to measure and hit the thresholds, and if the payload itself is the bottleneck, caching strategies is the next lever.

What about AI search and social sharing?

SEO used to mean Google, and Google alone could eventually run your JavaScript. That's no longer the whole game. A growing share of discovery happens through AI assistants and answer engines that crawl the web to ground their responses, through social platforms generating link previews, and through Bing powering more surfaces than its raw market share suggests. Many of these crawlers are less capable at JavaScript than Googlebot, not more — they read the raw HTML and stop.

That shifts the calculus further toward server rendering. If you want your content quoted by an AI assistant, previewed correctly when shared, and indexed by every engine rather than just the most sophisticated one, the safe move is to put the actual content — text, metadata, structured data — in the HTML the server sends, every time. Rendering strategy is now table stakes for being found at all, not just for ranking on Google.

Common mistakes even server-rendered sites make

Rendering on the server is necessary, not sufficient. We regularly audit "SSR" sites that still leak SEO:

Hydration mismatches that throw the client-rendered output out of sync with the server HTML, sometimes blanking content after load.
Meta tags and structured data set client-side, defeating the point — set them in the server response.
Shipping a massive JS bundle anyway, so hydration is slow and the page is interactive long after it looks ready.
Blocking crawlers in robots.txt or with aggressive bot protection that also turns away Googlebot.
Soft-404s and client-side redirects that crawlers interpret as broken or missing pages.

How to see what the crawler actually sees

You don't have to guess. Check it directly, in order of effort:

View source, not the DevTools inspector. The Elements panel shows the hydrated DOM after JavaScript runs — which always looks fine. Right-click and "View Page Source" (or curl\ the URL) to see the raw HTML the server actually sent. If your headline and body copy aren't in there, neither Googlebot's first pass nor a social bot will see them.
Use Google Search Console's URL Inspection tool. It shows the rendered HTML and screenshot Google produced, plus any indexing issues. This is the source of truth for what Google specifically got.
Test the social preview by pasting your URL into a debugger (LinkedIn, Facebook, Slack all expose one). A broken card is an immediate sign your meta tags are rendered client-side.
Disable JavaScript in your browser and reload. If the page goes blank, so does it for every crawler that doesn't run JS.

Run these before launch and after any framework or rendering change — regressions here are silent, and you often only discover them weeks later when traffic quietly fails to arrive.

The pragmatic rule

If a page needs to be found by search or shared on social, render it on the server or at build time — full stop. If a page lives behind a login and no crawler will ever see it, CSR is perfectly fine and often simpler; there's no SEO to lose. Most real products are a deliberate mix: a server-rendered public shell — marketing, content, product pages — wrapping a client-rendered authenticated app where SEO is irrelevant.

If organic traffic matters to your product and you're not certain your current stack renders for crawlers correctly, talk to us — checking exactly what Googlebot receives is one of the first things we audit, and it's often the cheapest SEO win a site can make.

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

How to secure your web app

Pykero — Thu, 09 Jul 2026 01:04:56 +0000

Security is easy to treat as someone else's problem until an incident makes it very much yours. The good news is that the vast majority of real-world breaches don't come from exotic zero-days — they come from a handful of well-understood mistakes. You don't need to be a security researcher to close them. You need a baseline, applied consistently. Here's the one every web app should have.

Get authentication and sessions right

Auth is where most serious failures start, so don't invent it. Use a battle-tested library or provider rather than hand-rolling password hashing and session logic.

Hash passwords with a modern algorithm like bcrypt or argon2 — never store them reversibly.
Manage sessions safely: short-lived tokens, secure and HttpOnly\ cookies, and proper logout that actually invalidates the session.
Enforce authorization on the server, every time. Hiding a button in the UI is not access control. Check permissions on the backend for every request, and default to deny.

Broken access control — a user reaching data or actions they shouldn't — is consistently among the most common and damaging web vulnerabilities.

Treat all input as hostile

Every piece of data from a client is a potential attack. Two classics still dominate:

Injection. Always use parameterized queries or an ORM — never build SQL by concatenating strings. This shuts down SQL injection at the source.
Cross-site scripting (XSS). Escape and sanitize any user-supplied content before rendering it. Modern frameworks help, but dangerouslySetInnerHTML\ and its equivalents will bite you.

Validate input on the server against a strict schema. Client-side validation is for user experience; it is not a security control, because anyone can bypass it.

Protect secrets and configuration

Credentials in your codebase are a breach waiting to be indexed. Keep secrets out of source control entirely — use environment variables or a secrets manager, and rotate them if they ever leak. Scan your repository history, not just the current files, since a key committed once lives in the history forever.

Ship secure headers and HTTPS

A few cheap defaults raise the floor considerably:

HTTPS everywhere, with HSTS so browsers refuse to downgrade.
Security headers — a Content-Security-Policy to blunt XSS, plus X-Content-Type-Options\ and frame protections.
CSRF protection for cookie-based sessions, using anti-CSRF tokens.
Rate limiting on auth and other sensitive endpoints to slow brute-force attempts.

Keep dependencies honest

Modern apps are mostly other people's code, and vulnerabilities in that code are yours to inherit. Run automated dependency scanning in CI, keep packages reasonably current, and be deliberate about what you add — every dependency is attack surface. A vulnerable library you forgot about is a common way in.

Make it a habit, not an event

Security isn't a checklist you complete once before launch; it's a posture you maintain. Bake these into your workflow: parameterized queries by default, secrets never committed, dependency scans in the pipeline, and authorization checks on every endpoint. Do the basics consistently and you'll be ahead of the majority of applications — and out of reach of the opportunistic attacks that cause most of the damage.

If you want a security review before you ship something that matters, talk to us.

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

How to scope a software project

Pykero — Thu, 09 Jul 2026 00:59:17 +0000

Almost every blown budget traces back to the same root cause: the project was never really scoped. Work started on a vague shared understanding, that understanding turned out to differ between the people paying and the people building, and the gap surfaced as overruns and hard conversations. Good scoping isn't bureaucracy — it's the cheapest insurance you can buy against a project going sideways.

Scope is a shared definition of "done"

The goal of scoping is a document both sides genuinely agree on: what will be built, what won't, and how you'll know it's finished. If the client and the team would describe the deliverable differently, you don't have scope yet — you have a misunderstanding waiting to be discovered mid-build.

Start from outcomes, then features

Begin with the outcomes the project must achieve, not a feature list. "Customers can subscribe and manage their own billing" is an outcome. "Add a billing page" is a feature that may or may not deliver it. Outcomes keep the conversation on value and make it obvious when a proposed feature doesn't serve one.

From each outcome, derive the features actually required to reach it — and notice the ones that don't map to any outcome. Those are usually the first things to cut.

Write down what's out of scope

The most valuable section of a scope document is what it excludes. Explicitly listing what you're not building in this phase prevents the slow, silent expansion that wrecks timelines.

Name the tempting features you're deliberately deferring.
State the integrations, platforms, and edge cases you're not covering yet.
Record assumptions — if one turns out false, that's a scope change, on the record.

Estimate in ranges, with buffer

Single-number estimates are false precision. Estimate in ranges that reflect real uncertainty, and add explicit buffer for the unknowns you can't see yet. Break work into pieces small enough to estimate honestly — anything you can't estimate is a research task hiding as a build task, and should be spiked separately first.

Make change control the plan, not the exception

Scope will change — requirements always do as everyone learns more. The mistake is absorbing changes silently until the budget quietly evaporates. Instead, agree up front on a simple process:

A change is proposed and written down.
Its impact on timeline and cost is estimated.
Both sides decide to include it, defer it, or trade it for something else.

Change control isn't friction. It's what lets you say yes to changes without lying about the timeline.

Phase it so value ships early

Scope the smallest coherent slice that delivers real value, ship it, then scope the next. Phasing surfaces wrong assumptions while they're cheap to fix and gets working software in front of users far sooner than a big-bang delivery.

At Doktouri we scope in the open — outcomes, exclusions, ranges, and a change process — so budgets hold and there are no ugly surprises at the end. If you're planning a build, let's talk.

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