Skip to content
Curiosive
TR
Netherlands · Agentic SaaS development

SaaS Development for Dutch Teams: Shared Edits and Conflict Review

Updated

Two people can have permission to change the same task and still disagree about its next value. If both start from an older screen, the second save may replace a change its author never saw. A collaborative SaaS brief needs to define what a save means, how a conflict is reviewed and which unfinished input remains available to its author.

Curiosive's published Netherlands project Lizzt rebuilt a Next.js frontend around an existing Supabase backend, with shared event workspaces and Dutch and English interfaces. That is delivered product evidence. The version checks, conflict screen and acceptance exercise below are proposed requirements for a new engagement, not claims about Lizzt's historical concurrency controls or offline behavior. Curiosive works remotely from Ankara, Türkiye; the portfolio country does not imply a local office.

Start a partnershipFrom $2,000 per month
24
published portfolio projects
5+
years building for production
12
countries the work runs in
100%
of code read by a senior engineer
1 day
to hear back, from the engineer

Start with the shared workflow the product already supports

Lizzt's published scope includes event tasks, items, costs, chat, participants, attendance and account workflows. A typed data layer uses SWR, while the existing Supabase backend remained in place during the frontend rebuild. For a similar product, identify the current read and write contracts before assuming that a frontend change can resolve conflicting writes. The case establishes shared-workspace and interface experience; it does not establish a particular subscription model, conflict-resolution algorithm or audited authorization policy.

Define a saved version and a private draft separately

Choose one record and the fields people may change. The screen should distinguish the version read from the server, the person's unfinished input, a pending request and the result the server confirms. Agree what happens when another participant's change arrives while the form is dirty. Replacing every field with the newest response may erase a draft; keeping every old field may hide a changed shared record. Define which values are shown together for review. A participant being online or allowed to edit does not, by itself, reserve the record for that participant.

Evaluate a stale save at the write boundary

Checking a version in the browser and sending an unconditional write later leaves a gap for another writer. Agree how the server evaluates the expected version together with the change and how the client distinguishes a conflict from permission loss or an unavailable record. RFC 9110 defines If-Match as an HTTP conditional-request mechanism used to avoid lost updates, using strong validator comparison. This is one possible contract where the API supports it, not a claim that an existing Supabase endpoint exposes that exact interface. PostgreSQL documents re-evaluation of an updating command's search condition after a concurrent update in Read Committed mode. Engineers can assess a conditional version update against that behavior; the database feature alone does not define the whole product workflow.

Walk through two editors changing task T-42

Use fictional task T-42 at version 17, with a Monday deadline and note 'bring cables'. Editors A and B both open it. A changes the deadline to Tuesday and receives confirmed version 18. B, still working from version 17, proposes Wednesday. For this exercise choose rejection of the stale save: Tuesday stays committed, B's proposed Wednesday stays available for review, and a deliberate new save uses the current version. Then repeat with B changing only the note. Decide whether the product still requires review or supports a separately specified field merge; do not silently submit B's older copy of the deadline. These are proposed checks, not observed Lizzt behavior.

Proposed two-editor worksheet: fictional task T-42, versions 17 and 18

  1. 1. Two different deadlines

    Ask
    What does B see when version 17's Wednesday proposal reaches a record already saved as Tuesday at version 18?
    Evidence to request
    A's confirmed version, B's base version and proposal, the conflict result and the deliberate resolution action.
    Tradeoff to record
    Rejecting stale saves makes review explicit; automatically accepting the last request can discard a change the second editor never saw.

  2. 2. An unrelated field changes

    Ask
    Can B add a note without restoring the older Monday deadline?
    Evidence to request
    The fields actually submitted, the current deadline and the agreed record-level review or field-merge result.
    Tradeoff to record
    A whole-record version rule can require review for independent edits; field merging needs its own rules and examples.

  3. 3. The save response is lost

    Ask
    How does A determine the outcome before repeating a request?
    Evidence to request
    The agreed request or change reference, the authoritative saved result and the visible unresolved state if that result cannot yet be established.
    Tradeoff to record
    A timeout is ambiguous. Matching current text does not by itself establish who wrote it, and an unconditional retry can overwrite later work.

  4. 4. A live update arrives during a draft

    Ask
    What happens to B's unfinished input when a notification arrives or the connection resumes?
    Evidence to request
    The draft kept for its author, a fresh authorized read of the shared record and the current version used for any later save.
    Tradeoff to record
    Refreshing shared state and replacing a dirty form are different actions. Offline queues and automatic reconciliation need additional scope.

Use live notifications without confusing them with save approval

Supabase documents Postgres Changes subscriptions for database changes, including event filtering and authorization considerations. A notification can prompt a screen to refresh shared data. It does not by itself specify how the application protects an older draft or adjudicates a competing write. Agree what a returning participant reads after reconnecting and how an event relates to the currently open record and version. Keep a live message, the result of the person's own save and the authoritative record distinguishable. A responsive interface or a live channel should not be presented as proof of an offline edit queue or automatic conflict resolution.

Agree one collaboration rule before expanding the product

Bring the current backend contract, one fictional shared record, two permitted editor roles and the T-42 exercise. Name the owner who decides which conflicting value should win and the engineer responsible for the write boundary. Agree record-level rejection, any field merge, draft retention and the response-loss check separately. Keeping an existing backend depends on what its actual interface supports; a frontend rebuild is not a guarantee that no backend change is needed. Customer file imports and exports have different review boundaries and can be scoped separately. Work is remote, with engagement scope and operating responsibilities confirmed in writing; no delivery outcome, office location or compliance certification is inferred from the stack.

Proof

Published project examples

Reveal Software

Reveal Software

Release Coach AI

Release Coach AI

Inspire Film

Inspire Film

Poppin

Poppin

Zing Coach

Zing Coach

ChurchBee

ChurchBee

AI-accelerated development
from$2,000
per month

Senior engineers building your product with AI coding agents: web, mobile, SaaS or browser extension, reviewed before anything ships.

  • Web, mobile, SaaS and browser extensions
  • AI-assisted delivery under senior engineer review
  • Scope and capacity agreed in writing, renews monthly

AI-accelerated development, billed monthly. We confirm scope, capacity and start date in writing before checkout.

Questions

The things people ask before starting.

Does a live update prevent two editors from overwriting each other?

Not by itself. Live notifications can refresh shared state, while the application still needs an agreed write contract for an older version and a review policy for unfinished input. The T-42 example chooses rejection of a stale save and deliberate resolution against the current version.

Does Lizzt establish that these conflict controls already shipped?

No. The published Netherlands case establishes a responsive Next.js frontend on an existing Supabase backend, shared event workflows and a multilingual interface. Version checks, the conflict screen, field merging and the worksheet here are proposed requirements, not claims about historical Lizzt behavior.

Can the frontend alone guarantee that a stale edit is rejected?

A browser check followed by an unconditional write leaves a race with another writer. The chosen backend contract must evaluate the expected version with the change. HTTP If-Match is one possible mechanism where supported; an existing Supabase interface must be assessed rather than assumed to provide that exact contract.

What should happen when two people edit different fields?

Choose the rule explicitly. A record-level version check may require another review even when fields differ. A field merge needs a definition of the base, current and proposed values, plus examples showing that a note update cannot silently restore an older deadline.

Related pages

Solutions
Locations

Mobile App Development for the Netherlands, with AI Agents

Locations

Software Development for Dutch Teams Extending Existing Products

Services

Agentic SaaS Development: Multi-Tenant Subscription Products

Locations

SaaS Development for North Macedonia: Billing, VAT and Tenants

How it starts

What happens after you write to us.

  1. 01

    You describe the product

    One paragraph on what you are building, roughly when you need it, and who it is for. No brief, no form with fifteen fields.

  2. 02

    You get a reply within a day

    From the engineer who would do the work, not a sales team. If we are not the right fit we say so, and where possible we point you somewhere better.

  3. 03

    You get a scoped plan

    Scope, price and timeline in writing before anything is committed. You decide with the numbers in front of you.

No long contract to begin, no lock-in to our tooling, and the code is yours from the first commit.

Start a conversation
Contact

Looking for an engineering partner for the long haul?

A short note about the product, the timeline and who it is for is enough to start. You will hear back from the engineer who would do the work, not a sales team.

hello@curiosive.comSee what we have shipped

Ankara / Türkiye · Working across European and US time zones