DEV Community: Devesh Pareek

Agency Handover: How to Get a New Engineer Productive in Week One

Devesh Pareek — Tue, 27 Oct 2026 14:00:20 +0000

Handing a codebase from an agency to a first in-house engineer goes better when the code is split by domain and each domain carries its own schema, API and tests. This is the structure we use at Deciphering Logic and what the first week looks like.

The problem with layer-based layouts

A lot of codebases are organised by layer: controllers, models, services, tests. That works while the same people write everything. It makes handover slow, because one feature is spread across every layer.

Take signup. The route is in one folder, the user model in another, the email verification in a service, the tests in a directory named after whenever they were written. A new engineer asking where signup lives gets a list of paths.

Organise by domain instead

A domain is one part of the product: onboarding, payments, admin, an AI layer if there is one. Each domain owns its tables, its API and its tests.

A layout like this:

onboarding/
  schema/
  api/
  tests/
payments/
  schema/
  api/
  tests/
admin/
  schema/
  api/
  tests/

Signup is onboarding. The user table, the signup endpoints, email verification and their tests sit under one directory.

The one rule that makes it work

No domain writes to another domain's tables. If admin needs a user's plan, it asks payments through the payments API.

That rule is what makes the folders mean something. Without it, the directories are cosmetic and a migration in one domain still breaks tests in another.

What each domain hands over

Data model: tables, columns, and which ones other domains may read through the API.
API: every endpoint, request and response shape.
Tests: runnable with one command, with a plain note on what each group covers.
Owner: a named engineer who answers questions about that domain.

The tests do most of the work. They describe what the domain should do and fail when someone changes that. A new engineer who runs them on day one has a baseline before editing anything.

Why admin goes first

Admin reads from most of the product and writes to little of it. Reading the neighbouring APIs from the admin side shows how the domains connect.

The risk is also lower. A bad admin change is a bug in an internal screen. A bad payments change touches money. So the hire takes admin in week one and we keep payments until they have read its tests and shipped a few changes elsewhere.

A week-one plan

Day one: run the admin tests with the domain owner, then read the admin API top to bottom.

Days two and three: read the APIs of the neighbouring domains, onboarding first. The contract is enough at this stage, the code behind it can wait.

By Friday: ship one small change to admin through admin's own tests. A list filter, a new field on a user page.

Payments keeps moving on its own backlog the whole time.

Checks that the handover worked

The hire finds where signup lives without asking anyone.
The admin change shipped without touching files in other domains. If it did touch them, the boundary is in the wrong place.
The hire has edited the owner notes or corrected an endpoint description.

When the hire has shipped several admin changes and read the payments tests end to end, payments moves over with the same four items.

If the agency already left

The domain lines can still be drawn afterwards. Map each table to a domain, list the endpoints, group the tests by what they cover. The old code may only loosely follow the result, but the new engineer gets one directory per domain to start from.

More on how we set up domain teams: https://www.decipheringlogic.com/teams

Originally published at decipheringlogic.com

Working With an Indian Team From Australia or NZ: The Daily Setup

Devesh Pareek — Tue, 20 Oct 2026 08:51:47 +0000

Setting up a daily handoff between ANZ and Jaipur

Working with a team in Jaipur from Sydney or Auckland has one constraint that shapes everything else. The round trip on a question is either minutes (inside the overlap) or about a day (outside it). Design around that.

The clock

IST is UTC+5:30 with no daylight saving. Sydney is UTC+10 (AEST) or UTC+11 (AEDT). Auckland is UTC+12 (NZST) or UTC+13 (NZDT). The gap runs from 4.5 to 7.5 hours and changes twice a year, because only your side moves.

Assuming a 9:30 start in Jaipur:

Jaipur	Sydney AEST	Sydney AEDT	Auckland NZST	Auckland NZDT
9:30	14:00	15:00	16:00	17:00
11:30	16:00	17:00	18:00	19:00
13:30	18:00	19:00	20:00	21:00

Inside a normal working day that is roughly 2.5 to 3.5 hours for Sydney and 1 to 2 hours for Auckland.

The daily loop

Five fixed points, same times every day:

Your morning: read the team's end-of-day note, answer every question in the thread before lunch.
Start of overlap: 15 to 20 minute call. Shipped, blocked, next. New work is briefed here, with the written brief already sent.
Middle of the day: the team builds. You do not get pinged unless something is blocked.
End of overlap: 20 to 30 minute review of what is on staging, on a screen share. Approve or send back with specifics.
End of the Jaipur day: the team posts the note below.

End-of-day note

A plain template is enough:

Done:

... Next:
... Blocked:
... Questions (numbered, each answerable in one line):
...
...

Numbering matters. You reply by number, so every answer maps to a question and nothing gets lost in a long paragraph.

Decision log

After each call the team posts what was decided: date, decision, owner. You confirm it or correct it in the thread. Keep it next to the specs, in the same wiki or repo, so it can be found later.

Treat a decision as made once it is logged. Before that, two people can leave the call with different versions.

Call or thread?

If a question needs more than two or three round trips, it goes on the call. Each round trip outside the overlap can cost a day.

On the call: scope trade-offs, unclear briefs, edge-case behaviour, what to cut this week, reviews of working software.

In writing: specs, acceptance criteria, bug reports with reproduction steps, anything someone will look up in three months.

Bring the question with the options listed. Whether refunds can be partial takes ten minutes. An open question about how payments should work takes the whole call.

Outside the overlap

The end-of-day note arrives in your evening or overnight and waits until morning. Agree what counts as urgent, such as production down or customers unable to pay, and give it one named channel. Everything else waits for the next window.

Common failure modes

The call grows past 20 minutes. Cut the agenda back and move detail into a written doc.
Questions arrive as one long paragraph. Number them.
Decisions happen in direct messages. Move them to the thread and log them.
The calendar breaks when your clocks change. Check both clocks that week, since the Jaipur side does not move.
Nobody posts the note. Name one owner per thread on each side.

Thread layout

One thread per part of the product: payments, onboarding, admin, and so on. It follows the way DL splits teams, one small team per domain, and it keeps each note short enough to read in a couple of minutes.

Originally published at decipheringlogic.com

EU AI Act Compliance Checklist for Scale-Up CTOs

Devesh Pareek — Thu, 08 Oct 2026 13:48:44 +0000

EU AI Act: The Engineering Decisions That Actually Matter Before You Ship

Most of the EU AI Act coverage focuses on fines and timelines. This post focuses on the decisions that affect your architecture, your data pipelines, and your team's sprint planning right now.

Start with risk classification

The Act uses four tiers: unacceptable, high, limited, and minimal. Where your system lands determines almost everything else. High-risk is not based on your intent — it is based on use case and domain. Hiring tools, credit scoring, medical device software, and critical infrastructure management all land in high-risk regardless of how the underlying model works.

If your model's output feeds into a decision in one of those domains, start from the assumption of high-risk and work backwards. Classification is a written decision, not an internal assumption. Assign an owner and get legal sign-off.

Technical documentation is an engineering problem

For high-risk systems the Act requires a technical file with specific contents:

System description and intended purpose
Design logic and key design choices
Training, validation, and testing data and methodology
Accuracy, robustness, and cybersecurity metrics
Risk management documentation
Post-market monitoring plan

The documentation gap most teams have is in dataset provenance and the risk management log. If you are running MLflow or Weights and Biases, your experiment logs are the raw material. The missing piece is usually a dataset registry that records source, collection date, labeling methodology, and known limitations.

Build the systems that generate this documentation from your existing tooling rather than writing it by hand. Hand-written compliance documents go stale immediately.

Human-in-the-loop is an architecture decision

The Act requires that humans can understand, monitor, and intervene in high-risk system outputs. That is a spec, not a policy. In practice:

Automated actions with no review step are a compliance gap for high-risk classifications
Outputs must be interpretable enough that a reviewer can understand why a decision was reached
Every decision must be logged and traceable

Building HITL as an afterthought means building a review queue nobody uses. Design the intervention surface and the escalation thresholds into your model serving layer before the first production release.

Data governance additions on top of GDPR

The Act does not replace GDPR. For high-risk systems, training data must meet quality criteria — relevant, representative, free of significant errors. You need to be able to demonstrate this on request.

Key questions:

Do you have a dataset registry?
Can you produce it for a regulator or enterprise buyer?
If training data included EU personal data, do you have a documented lawful basis?
What is your process if a training dataset needs to be pulled after deployment?

The last question is the one most teams cannot answer cleanly. Retraining or retiring a model quickly when a data source is found to be problematic is an operational and architectural requirement, not just a legal one.

GPAI deployer obligations

If you are building on a foundation model rather than training your own, you cannot outsource compliance to your model provider. Their GPAI compliance covers their obligations. Your application-level risk classification, any fine-tuning you apply, and the transparency requirements of your deployed system are still yours.

Get the technical documentation from your model provider. If they cannot provide it, treat it as a vendor risk issue.

What to do in the next 30 days

Produce a written risk classification for each AI system you are shipping or planning to ship this quarter. One page per system, legal sign-off required.
Run a gap analysis against the high-risk technical file requirements for any system that lands in that tier.
Make the HITL architecture call before the next sprint for any high-risk system, not as a later iteration.

These are small decisions in terms of time. They have large downstream effects on your architecture and your vendor contracts.

Originally published at decipheringlogic.com

Building a Restaurant Loyalty App That Talks to Your POS

Devesh Pareek — Thu, 01 Oct 2026 06:01:09 +0000

Building a Restaurant Loyalty App That Talks to Your POS: The Integration Decisions That Actually Matter

The loyalty logic in a restaurant app is not complicated. Points accrue on purchase, rewards redeem at a threshold, referrals credit when a new guest completes a qualifying visit. You can model that domain in an afternoon.

The POS integration is a different problem entirely. It's where most restaurant-tech builds stall — not in the planning phase, but in week four of development when the team discovers that the POS only exposes data via hourly batch exports, or that bidirectional redemption requires a vendor partnership agreement nobody had applied for.

This post covers the technical decisions that need to be made before a line of code is written.

Start with the POS surface area

Before you design anything, know exactly what your POS exposes and how.

Cloud-native platforms (Toast, Square, Lightspeed, etc.) typically offer REST APIs with OAuth, sandbox environments, and reasonable documentation. Integration scope is predictable.
On-premise or legacy systems may expose data only through a local database, a proprietary SDK, or scheduled CSV exports. Middleware is often required.
Franchise-managed platforms sometimes gate API access behind a developer or partner program. This takes time to apply for and isn't guaranteed.

The first technical spike in any POS integration project should be: authenticate against the sandbox, pull a transaction record, confirm the data model. If you can't do that in a day, you've found a constraint worth escalating before architecture decisions are made.

Map each data flow explicitly

There are at least four distinct flows in a loyalty-plus-POS system, and they have different latency requirements and failure modes:

Flow	Direction	Latency	Failure impact
Transaction events	POS → loyalty	Near real-time or per-session	Points not awarded
Reward redemption	Loyalty → POS	Real-time at checkout	Double redemption or failure at register
Menu/item data	POS → loyalty	Daily sync usually sufficient	Stale data in app
Customer identity	Bidirectional	At transaction time	Misattributed points

Redemption is the most operationally sensitive. If the loyalty app times out during a checkout and the POS can't confirm the discount, the cashier is stuck. That failure mode needs a defined fallback — manual override code, offline redemption queue, or graceful degradation — before you're in production.

The identity problem

Your loyalty app knows the customer. Your POS knows the transaction. They don't automatically agree on who made the purchase.

Common matching approaches:

Phone-number lookup at register — low technical complexity, high dependency on cashier discipline. Expect a non-trivial miss rate in practice.

QR code from loyalty app — works well in counter-service contexts, adds a step to the checkout flow. Reliable when customers use it.

Card-on-file linkage — cleanest UX, depends on payment processor support (not just POS support). Not universally available.

Whichever method you choose, design your attribution logic around its realistic failure rate. If 15-20% of transactions won't be attributed, your points balance display, dispute handling, and campaign logic need to account for that gap.

Offline behavior

Restaurant environments lose connectivity. Food trucks, basements, festival stalls — these are real deployment contexts. Your integration needs an explicit position on what happens when the POS can't reach your loyalty backend.

The standard approach is local transaction queuing on the POS with sync-on-reconnect. Points are awarded on sync, not in real time. This is acceptable for most use cases but breaks time-sensitive promotions and real-time redemption validation.

For multi-unit or franchise deployments, offline behavior needs to be consistent across locations. Inconsistency at this level becomes a support and trust problem at scale.

The data model consequences of multi-location rules

If a customer earns points at location A and redeems at location B, your data model needs to represent that clearly. If referrals can cross locations, you need a transaction-level location attribute on every event.

These seem like business rules. They are — but they have schema-level consequences. Adding cross-location attribution to a data model that wasn't designed for it is a migration, not a feature flag.

Get the business rules documented before the schema is designed. That's the constraint.

What a pre-build integration spec should contain

Before development starts, you want a document that covers:

POS platform, API version, authentication method, sandbox access status
Each data flow: direction, trigger, latency requirement, failure fallback
Identity-matching method and expected attribution rate
Offline behavior per integration point
Multi-location data ownership and cross-location loyalty rules
Redemption UX at the register and how it maps to POS API capabilities

Without this, the development team makes these decisions in code, under time pressure. Those decisions are expensive to reverse.

On the build itself

The Grill Masters Pro Shop loyalty and referral system — a product we shipped — is an example of a build where POS integration was scoped before prototyping started, not discovered during development. The upfront questions about which POS, which data flows, and how redemption would work at the register shaped the architecture from the start.

That scoping work is not glamorous. It's also the difference between a build that ships and one that stalls.

Originally published at decipheringlogic.com

What Does a Clickable Prototype Actually Cost in 2026?

Devesh Pareek — Thu, 24 Sep 2026 13:15:18 +0000

What Actually Drives App Prototype Cost in 2026?

Most quotes non-technical founders receive for a "prototype" are actually quotes for a working product. The distinction matters because the cost difference is significant and the decision of which one you need is usually not technical — it is about what stage you are at.

This post is aimed at developers and technical leads who advise founders, or who are themselves building something on the side. Understanding how prototype cost breaks down helps you scope better and set expectations earlier.

The three variables that drive cost

Scope is the dominant factor. A prototype covering a single user flow — onboarding through one primary action — might take 40-60 hours of design time in a tool like Figma. A second user role roughly doubles that. A third flow with branching states doubles it again. Founders often describe four flows in a single paragraph without realizing it, and the scope estimate they receive reflects all four.

Fidelity is the second variable. Low-fidelity wireframes (grey boxes, placeholder copy) are faster to produce and better for early concept testing because users focus on flow rather than visual detail. High-fidelity prototypes (real brand, real copy, realistic interactions) cost $3,000-$5,000 more but are generally what you want for investor meetings or usability testing where visual credibility matters.

Integrations are where people get caught. A Figma prototype simulates data — there is no real API call. But some founders specifically need a live payment flow, a real calendar integration, or an actual EHR data pull to validate something specific. That requires code. A coded prototype with real integrations costs 3-5x more than a design prototype and takes longer to build. It is sometimes the right call, but most founders at the idea stage do not need it.

What a prototype quote should include

A few things to check when reading a prototype estimate:

Screen count: "as needed" is not a scope. Get a number.
Revision rounds: time-capped or unlimited? Unlimited on a fixed-price engagement means the cost is hidden somewhere.
Build plan: a Figma file without technical documentation leaves the founder with no way to get a reliable engineering quote. The build plan — stack recommendations, integration requirements, rough cost range — should be included or explicitly priced.
Coded vs. design prototype: make sure the quote matches what was actually asked for. These are different products.

Why the build plan matters as much as the prototype

A clickable prototype answers the question: does this feel right to users and investors? A build plan answers the question: what would it actually take to build this? Without both, a founder either has something pretty with no engineering path, or a rough cost estimate with no way to communicate the product.

The gap between prototype and build is where a lot of early-stage projects stall. Developers get handed a Figma file and a vague description. They make assumptions. Those assumptions cost money to unwind later.

A build plan that covers the data model at a high level, the external integrations required, the non-obvious technical decisions (auth, offline support, multi-tenancy), and a sequenced feature roadmap for v1 gives an engineering team something to actually work from.

Rough cost ranges for 2026

Type	Typical range	Timeline
Low-fidelity wireframes, single flow	$1,500 - $3,000	1 week
High-fidelity prototype, single flow	$4,000 - $7,000	2 weeks
High-fidelity prototype, two user roles	$7,000 - $12,000	2-3 weeks
Prototype + build plan	$5,000 - $10,000	2 weeks
Coded prototype with real integrations	$15,000 - $30,000	4-8 weeks

These ranges assume a competent product design team working against a reasonably clear brief. Offshore rates in some markets will be lower; US-based boutique agencies will be higher.

A note on timeline

Two weeks is realistic for a single-flow, high-fidelity prototype. Three weeks for two user roles. If a quote says six weeks for a prototype, ask what is filling the time. Sometimes that reflects a team structure where design and feedback cycles are stretched across calendar time rather than compressed. Sometimes it is just padding.

Compressing a prototype to 14 days forces scope decisions early. That is uncomfortable but useful — it surfaces the question of what is actually in v1 before anyone starts building.

The practical takeaway for developers advising founders

When a founder you know says they received an $80,000 quote for their app idea, ask whether anyone scoped it as a prototype first. The answer is usually no. The agency answered the question they were given.

A prototype engagement that produces a high-fidelity interactive demo and a build plan costs a fraction of a full build and gives both the founder and the future engineering team what they actually need to make a good decision about what to build next.

Originally published at decipheringlogic.com

Building a candidate Readiness Score for a healthcare staffing marketplace

Devesh Pareek — Wed, 16 Sep 2026 11:42:07 +0000

Wanderly is a travel healthcare staffing marketplace: 663,000+ registered candidates, 500+ agencies. Recruiters there had one recurring question: of the thousands of candidates in my list, who do I call first?

We built a Readiness Score to answer it. This is the version-one model, the reasoning behind its shape, and what we deliberately left out.

## Three signals, not eight

The full design had eight signals: recency, job views, clicks, applications, email and SMS engagement, an opt-out penalty, campaign participation, profile completeness. It was a good model. We shipped three:

Campaign engagement, 50%
Application activity, 30%
Profile completeness, 20%

Fewer signals meant the score was explainable to a recruiter in one sentence, and it meant we could validate the model against sixty days of real pilot data before adding anything.

## Recency decay

Campaign engagement is decayed by recency: activity in the last 30 days counts at 1.0x, 31 to 90 days at 0.7x, 91 to 180 days at 0.4x, and nothing beyond the configured window. A reply from last week and a reply from five months ago are not the same signal.

## Hard overrides

Some things are switches, not inputs.

Opt-out (a STOP reply): score forced to 0 and the candidate is removed from every campaign audience, regardless of any other signal.
Twelve months of total inactivity: score capped at 25.
New candidate with no history: scored on profile completeness only, shown with a New badge.

Compliance sits outside the model. A weighted penalty can be outvoted by other signals; a hard override cannot.

## Tiers

Hot 70 to 100. Warm 40 to 69. Cold 20 to 39. Inactive 0 to 19. Minimum campaign-eligible score: 20. Weights are locked for v1; admins configure the time windows and the tier thresholds.

## What the recruiter sees

The number, a colour, and a breakdown: Campaign engagement 42/50, Application activity 24/30, Profile 18/20, based on the last 6 months. Opted-out candidates are flagged, not hidden.

## What we left for v2

Behavioural events (job views, time on job detail, pay comparisons, saves), agency-specific weights, and a second scoring mode for agencies that use the marketplace without the campaign product. All of it waits on real data from v1.

Originally published at decipheringlogic.com

Wanderly case study

Devesh Pareek — Wed, 16 Sep 2026 10:18:02 +0000

Building a candidate Readiness Score for a healthcare staffing marketplace

We built a Readiness Score to answer it. This is the version-one model, the reasoning behind its shape, and what we deliberately left out.

## Three signals, not eight

Campaign engagement, 50%
Application activity, 30%
Profile completeness, 20%

Fewer signals meant the score was explainable to a recruiter in one sentence, and it meant we could validate the model against sixty days of real pilot data before adding anything.

## Recency decay

## Hard overrides

Some things are switches, not inputs.

Opt-out (a STOP reply): score forced to 0 and the candidate is removed from every campaign audience, regardless of any other signal.
Twelve months of total inactivity: score capped at 25.
New candidate with no history: scored on profile completeness only, shown with a New badge.

Compliance sits outside the model. A weighted penalty can be outvoted by other signals; a hard override cannot.

## Tiers

Hot 70 to 100. Warm 40 to 69. Cold 20 to 39. Inactive 0 to 19. Minimum campaign-eligible score: 20. Weights are locked for v1; admins configure the time windows and the tier thresholds.

## What the recruiter sees

The number, a colour, and a breakdown: Campaign engagement 42/50, Application activity 24/30, Profile 18/20, based on the last 6 months. Opted-out candidates are flagged, not hidden.

## What we left for v2

Originally published at decipheringlogic.com