DEV Community: Devesh Pareek

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