Why now

The main reason is of course regulation. Article 50 of the EU AI Act has applied since August 2, 2026. It requires AI providers to mark generated content in a machine-readable way, so it can be decteted more easily. This includes any company with EU users, not just European ones. Fines can reach €15M or 3% of global turnover. Similary, California’s SB 942 takes effect on the same date and requires hidden disclosures from providers with more than a million users in the state. Because two major markets have the same rule starting on the same day, AI providers now have to comply.

How it works

A language model guesses one word at a time when writing and it often has more than one equally good options for the next word. After “The weather today was cold and…”, both “overcast” and “grey” fit. Normally a random number generator picks between them.

Claude uses SynthID-Text, a method developed by Google DeepMind and it replaces that random pick with a rule based system that uses secret key and the words that came just before. With a small text it’s not as efficient but with over hundreds of words, though, it builds a statistical pattern that a detector with the key can measure.

According to Anthropic:

• Quality doesn’t change. The model only chooses among options it already rated as equally good and Google DeepMind’s testing found no significant difference in user ratings.
• Users pay nothing extra. The watermark adds no extra tokens.
• The watermark contains nothing about the user. It can’t be traced to a person, an organization or a chat.

Code gets very little watermarking, since there’s rarely a choice between equally good options. Images get C2PA metadata instead: a signed record that Claude was involved but a screenshot or re-save can strip it and Anthropic is also adding watermarks to older Claude models over the coming months.

What it can’t do

• Short or factual text gives a weak signal, because there are few word choices to use the pattern.
• Editing weakens it. Copy paste keeps the watermark of couse but heavy editing weakens it and a full rewrite can even remove it.
• It can’t show authorship. It can’t tell whether Claude wrote a piece or only enhanced it.
• Common AI detectors can’t read it. GPTZero and Turnitin are still guessing from writing style. The real detection API is in private preview for regulators, researchers, media, schools and fact-checkers.

What to do about it

If you’re a freelancer or run a studio that uses AI in client work, stop treating AI use as something to hide. Write a clear disclosure policy that says when and how clients learn AI was involved and put it in your contracts. Now that AI involvement can be checked, being open about it costs you nothing and getting caught hiding it can cost a lot.

Watermarks won’t end misinformation and a determined person can still get around them. But they change the default: most AI text will now carry a quiet signal of where it came from.

Sources:

• https://www.layer3labs.io/guides/ai-watermarking
• https://www.anthropic.com/news/claude-text-watermark

The post Your AI Text Now Has a Hidden Fingerprint appeared first on Mobile USTP MKL.

Why not Figma or Canva?

All three big design tools now have AI. Figma puts it inside a professional canvas and coding agents can even design directly in your files. Canva AI 2.0 creates layered, editable designs from a conversation. It’s great for marketing material, but it isn’t built for app UI.

For OnTime, the question was simple: who is the designer on this project? I’m a solo developer. I had a design system in Figma to build on but I wanted something new. Claude Design can read images and design or even codebases and extract its colors, typography and components, so it was an easy choice.

The start

V1 already had parts I wanted to keep, like the week calendar with drag-to-create entries and the live recorder. A new look wasn’t the only reason I decided to design a new UI. It also needed to fit a much bigger app around that core: workspaces, roles, invoices and bank reconciliation.

So I didn’t start with a blank prompt but I gave Claude Design my previous design and it built a design system from them. Then I asked for the new screens. It made the iteration faster but it also needed a lot of help finding the correct design. It was by far not a single-prompt-execution and it took a lot of trial and error to get to a useable state.

• Overview: V1’s overview had bar and pie charts. For V2, the overview got more animated stat cards, an activity heatmap and a project split.
• Calendar: This screen changed the least. The work here was mostly styling it to the new design and adding a new entry design so it’s more compatible for multi-user support.
• Table pages: The table pages consist (well) just pages, so the main thing was to add the new design layout and archivable entries with a switch.
• Notifications: Funnily enough, this page was the hardest to design because the plain table design didn’t feel right. I decided to use cards for each notification with views for read and unread messages.
• Invoices and payment review: These screens were new, so there was nothing from V1 to copy. But since it was also one of the last pages I got to, it was easier to find a fitting design.

From design to code

The implementation took the longest to do because I rebuilt everything by hand in React. Claude Design lets you export your website as code but without any framework. I could’ve moved around it to let Claude generate everything but I wanted to do the programming side on my own. The mobile shell sits behind its own build flag in the app so switching the flag for testing on desktop was easy to do.

What worked, what didn’t

What worked:

• Exploring was nearly free. I tried a lot of directions for the design and the different pages before settling on one.
• The design system stayed mostly consistent across screens without me policing it.

What didn’t:

• The spacing not always stayed consistent.
• Not explaining your idea in detail leads to disappointing results.
• Design may look generic.

Takeaway

For a solo developer, the design phase used to mean switching tools: design in Figma, then translate it into code by hand. With Claude Design, but now you can make Claude do the heavy lifting. Even though I decided to implement the design myself in code, it designing of the actual website was way faster and I was able to test a lot of different directions. The decisions stayed with me: what gets attention first, what stays from V1, what a finished page should look like. Claude did the designing and I made the design decisions.

The post Designing OnTime V2 with Claude Design appeared first on Mobile USTP MKL.

V2 lives in a new repository, but it is of course built on Version one. The tracker is still at its core and around it, OnTime now handles teams, invoices and payments.

What changed

In V1, one person tracked their own time but in V2, everything happens inside workspaces. A workspace can consist of just you or a whole team and every member has one of four roles: owner, admin, manager or member.

But the basics are of course still there: a timer, manual entries and clients, projects and tasks with their own detail pages. The calendar is now shared and even updates live across devices. Projects can have budgets that send a notification when they cross a threshold. The whole app is in English and German and on mobile it works offline thanks to a persisted query cache.

Invoices and payments

This is where V2 changes the most from its previous version. Billable time becomes an invoice and when you send it, an Edge Function renders it as a PDF and freezes it. If you edit the underlying time entries later, the document the client already received doesn’t change.

Additionally, OnTime connects to your bank through Enable Banking. The connection is read-only by design and you bring your own credentials, which are stored encrypted in Supabase Vault. A scheduled pg_cron job pulls in transactions and matches them against open invoices. When a match is confident, the invoice is marked paid automatically. Everything else waits in a queue for one-click review.

Database changes

V1’s database only had to serve one person tracking their own hours. V2 needed a real data model, so I didn’t patch the old schema and started from the start.

As said before, Everything belongs to a workspace: Clients, projects, tasks, time entries and invoices all hang off a workspace and every row knows which workspace it belongs to. That one change is what makes teams possible. It’s also what the security model is built on.

Also, every table has row-level security policies that check the caller’s workspace and role before returning a single row. Views run with security_invoker, so they apply the permissions of the person querying them instead of quietly bypassing them. Owners, admins, managers and members all hit the same tables and get different answers. Since the frontend isn’t trusted to enforce any of this, pgTAP suites test the rules against a real database.

Another security measure was to add a timestamp to entries when they get deleted. Now they are moved to a trash view, where they can be restored. A pg_cron job purges them for good once they’ve been in the trash long enough, so nobody has to clean up by hand.

An invoice can’t point at time entries and hourly rates, because those can change or be edited. When an invoice is sent, it stores a JSONB snapshot of everything it was built from and the PDF is frozen alongside it. Rates also keep a history, so billing a project in March uses March’s rate even if it went up in June. Invoice numbers are generated per workspace and restart each year.

pg_cron also triggers the bank sync so that transactions come in on a schedule, get matched against open invoices and confident matches mark the invoice as paid. The bank credentials never sit in a plain column and are encrypted in Supabase Vault.

The shared calendar and the notifications subscribe to database changes through Supabase Realtime. When someone stops a timer on their phone, the entry shows up on everyone else’s desktop without a refresh.

Testing

Tests run in three layers:

• Vitest for units and components
• Playwright end-to-end tests against a preview build
• pgTAP for the security rules

Unit and end-to-end coverage are combined into one number and uploaded to Codecov on every CI run. Right now I have about 40% coverage but that will still be improved in later versions.

The post OnTime V2 appeared first on Mobile USTP MKL.

What Is an Agent Harness?

Finding a clear-cut definition of an “agent harness” isn’t easy. This is largely because many AI companies are reluctant to give away the exact approach of how their agents work, often disguising the technical definition in marketing jargon that sounds cool or magical (definitions e.g.: Google, OpenAi, Anthropic).

The best difinition I could find was one I stumbled over reading a Github repo about “Best of Agent Harnesses and Harness Techniques” which quoted a Blog entry from Simon Willison’s Weblog: “An LLM agent runs tools in a loop to achieve a goal.” (6)

Technically speaking, an agent harness is the infrastructure and control layer built around a Large Language Model (LLM). A base model (like Claude 3.7 or GPT-4o) cannot natively search your local files, execute terminal commands, or iteratively fix code—it only generates text. The harness is what grants the LLM autonomy. It provides the model with tools, enforces permissions, manages state, and orchestrates the overarching loop of an agentic session. (1)

Inside Claude Code: Architecture Overview

When we examine the architecture of a sophisticated harness like Claude Code, it reveals a highly structured system that goes far beyond a simple chat interface.

At its core, the architecture relies on a continuous evaluation loop. The model isn’t just generating an answer; it’s navigating a Gather-Act-Verify cycle. (2)

graph TD
    A[User Input / Prompt] --> B(Agent Harness Control Loop)
    B --> C{LLM Decision Engine}
    
    C -- Needs Context --> D[Gather]
    D --> D1(Search Files, Read Memory)
    D1 --> B
    
    C -- Ready to Execute --> E[Act]
    E --> E1(Write Code, Run Terminal)
    E1 --> B
    
    C -- Needs Validation --> F[Verify]
    F --> F1(Run Tests, Check Linting)
    F1 -- Error Found --> B
    F1 -- Success --> G[Final Response to User]

Another crucial component of this architecture is Memory Management. Developer Simon Willison highlighted a fascinating architectural detail in a recent blog post comparing the memory implementations of Claude and ChatGPT. (2)

Claude’s harness philosophy prioritizes extreme transparency. Unlike OpenAI, which often injects user profiles or past context into the background automatically, Claude Code starts every conversation as a blank slate. Memory is implemented as explicit tools (specifically conversation_search and recent_chats).

sequenceDiagram
    participant User
    participant Harness
    participant LLM
    participant MemoryDB
    
    User->>Harness: "Continue where we left off yesterday"
    Harness->>LLM: Pass user prompt
    LLM->>Harness: Tool Call: conversation_search()
    Harness->>MemoryDB: Query past logs
    MemoryDB-->>Harness: Return relevant context
    Harness-->>LLM: Inject context into prompt
    LLM->>User: "Ah yes, we were fixing the routing bug..."

Because the model decides when to pull from memory via a visible tool call, you avoid the issue of old “bug loops” silently poisoning a fresh workspace.

Building Your Own Agent Harness and the benefits

But why should you build your own agent harness when they already exist and work fine? I think its just the same reason why open source software exists. Closed-source systems like Claude Code are incredibly powerful, but they are highly opinionated and tailored to specific workflows (like general software development). By building your own, you gain maximum flexibility.

You can customize the exact tools the agent has access to, perhaps integrating it directly with your company’s proprietary databases, Jira ticketing systems, or internal APIs. Or you can just adjust it for your needs for software developement or general purpose use. Fortunately, you don’t have to start from scratch. An excellent starting point is the GitHub repository RyanAlberts/best-of-Agent-Harnesses. (4) This curated, weekly-updated list ranks over 100 open-source agent harnesses. Notably, it even includes an MCP (Model Context Protocol) server, llms.txt, and JSON data, allowing agents themselves to read the repository and recommend the best harness framework for your specific needs.

For what would i use a “Harness” for?

To understand the practical value, let’s look at a real-world project I am doing at work: a system designed to fully automate the production of AI-generated videos.
To be honest, the architecture diagram below represents a highly structured pipeline rather than a full-blown autonomous harness, because I have to make it highly predictable. However, it perfectly illustrates the foundational steps. By giving the central “Orchestrator” more flexibility and decision-making power, this pipeline could easily evolve into a true agentic harness.

How would this be agentic then if we give it more freedom to be “creative”. If we apply the Gather-Act-Verify principles discussed earlier to this exact diagram, the system becomes truly autonomous:

• Gather (Data & Script Prep): Instead of just following a static script, the agent uses tools to autonomously query the AWS Database for the latest product stats and fetches the correct Presentation Assets (potentially using the Model Context Protocol, MCP, to search through company directories).
• Verify (Validation & Creation): This is where a harness shines. In a rigid pipeline, if the Small compliance/Legal check fails, the system just throws an error and stops. In an agent harness, the LLM catches this error, analyzes why the script failed compliance, and autonomously rewrites it until it passes the check.
• Act (Audio, Sync & Rendering): Once the agent verifies the script is perfect, it triggers the text-to-speech tools, gathers the exact audio timestamps, and hands everything over to the rendering engine before finally publishing it.

Challenges and Best Practices

If you decide to build a custom harness, keep these best practices in mind:

1. Cost and Latency Control: Because the agent runs in continuous loops (sending accumulating context back to the model), API costs can skyrocket. Implementing effective Prompt Caching is mandatory. (5)
2. Robust Error Handling: If a tool (e.g., a terminal command) fails, the harness must not crash. It needs to gracefully catch the error (like a stack trace) and feed it back to the LLM during the Verify phase so the agent can self-correct. (5)
3. Transparency: Follow Claude’s example. Don’t hide memory injections in the system prompt. Implement memory and context retrieval as visible tool calls so users can audit what the agent is doing. (6)
4. Sandboxing: Because the Act phase allows the execution of commands, your harness must enforce strict security boundaries (e.g., running actions inside Docker containers) to prevent an autonomous agent from accidentally deleting critical system files. (5)

Conclusion

An agent harness is much more than an API wrapper, it is the vital infrastructure that gives a language model the tools it needs. While leaks and teardowns of commercial tools like Claude Code give us a glimpse into high-end, proprietary architectures, the vast open-source community proves that custom, bespoke solutions are more accessible than ever. By mastering the Gather-Act-Verify loop and maintaining clean, transparent tool management, you can transform a simple text generator into an autonomous, specialized digital colleague.

Btw: There is also a very good video if you want to know more about harnesses from Langchain: https://www.youtube.com/watch?v=HI2q3ci3Iuc&t=409s

Sources

1. https://vrungta.substack.com/p/claude-code-architecture-reverse
2. https://michaellivs.com/blog/architecture-behind-claude-code
3. https://www.mindstudio.ai/blog/claude-code-source-leak-memory-architecture
4. https://github.com/RyanAlberts/best-of-Agent-Harnesses
5. https://resources.anthropic.com/building-effective-ai-agents
6. https://simonwillison.net/2025/Sep/18/agents/

The post Creating your own custom Agent Harness like Claude Code and why it matters appeared first on Mobile USTP MKL.

When I started out, I decided to make an application that was really worth trying. I designed a database structure and a system architecture that I meant to be perfect. But for my first frontend (tbh not only the frontend), I was struggling. I am no designer myself and couldn’t really create a smooth user flow, so I used AI to help me with that. After I was done, I wasn’t very happy with either the scalability or the look and feel. I had used Ionic, a web framework that ran in a WebView on the device. The touch inputs didn’t feel instant or responsive enough, and for what was basically a simple CRUD app, it felt a little bit sluggish (or maybe that’s just me).

So, in my second semester, I focused on refining that whole experience and making it better in every way.

The Rewrite: Embracing Kotlin Multiplatform

I decided on a new frontend framework: Kotlin Multiplatform (KMP), which allows you to build apps for nearly any platform using a shared codebase. I also added new features, like self-hosted AI solutions to generate content and a posibility to choose your current Gym.

Implementing my app with Kotlin was challenging because it was a completely new programming language to me. After learning the fundamentals and coding on my own for the first week, I brought in some AI coding agents to help speed up the process. At first, I used a local model called qwen3-coder:30b, which I quantized to run on constrained hardware. My setup was a Mac Book Air M1 from the USTP rental service running OMLX (which was especially built for Macs to take advantage of their unified memory). Running in my IDE was the open-source AI code agent Continue, which allowed me to implement MCP servers and feed code context from my project to the model. Later I learned that this extention or IDE whatever you wanna call it, is no longer being developed and was acquired by Cursor.

After I sadly had to return the rental Mac (originally i wanted to use it for building the App for IOS as well but just failed to finish the App in time ) , I switched to Claude Code. For me, it was essential to double-check Claude’s work and architectural decisions. Honestly, I was a little bit shocked by some of the choices it made, like trying to store API keys or passwords in plain text just somewhere in the Code! To be fair, I wasn’t using their frontier model to avoid spending too many tokens (as I argued a lot with it during the development process), but still. However, it was particularly handy for creating the frontend layer with Jetpack Compose, thanks to the vast documentation available for Android’s UI framework.

To avoid hallucinations and provide the model with up-to-date documentation, I added an MCP Server called Context7. It allowed me to filter exactly what documentation the model received and what it had access to … a really handy tool.

Frontend Challenges: Caching, Offline Sync, and Navigation

The hardest part of my frontend implementation was the caching logic. I wanted the app to always instantly display the relevant information you need in the moment. To achieve this, I decided to cache the first 10 items of every category (e.g., Templates, Trainings, UserData).

All of this is stored in a Key-Value database called KStore, a small library that works great for simple data storage on Android and iOS devices. The absolute hardest part was defining the behavior for when I saved something offline, ensuring that the moment I got back online, it would post to the backend so the two storages would “sync” up again. We now have a (mostly) robust network-first cache strategy with offline fallbacks.

I also completely revamped the app’s navigation and UI architecture using Compose Multiplatform:

• Two-Level Navigation: We have an outer navigation graph for the Auth-Flow (Login/Register) and an inner graph wrapped in a Scaffold for the main tabs. This allows for a persistent BottomBar that stays visible while you switch tabs.

• Profile Dialog: Instead of routing to a new screen, the user profile opens as a clean Dialog Card over the current screen, making it feel much faster.

• Security: Tokens are stored securely using KVault (Keychain for iOS, EncryptedSharedPreferences for Android).

• Dependency Injection: I used Koin to keep the architecture clean (MVVM), allowing the UI to remain logic-free.

The Backend: Keeping it Clean & Adding a Scraping Service

For my backend (a self-hosted NestJS API), I tried to make major improvements to security and code cleanliness. Most of my backend wasn’t even touched by AI … I mean aside from a few MongoDB queries … they’re just really weird to write ok? … so I could assure everything was up to my expectations.

For extended features, I added a custom scraping service using a separate Python server. It scrapes all the fitness studios listed on my gym’s website and writes everything about their equipment directly into my database. It’s scheduled to run on startup and then one time per Month (don’t want to get accused of creating to much net traffic for them). I deployed this service in a separate Docker container within the same Docker network to ensure minimal downtime in case the scraper ever crashes.

Building a Local AI Agent for Training Templates

Having the exact context of my gym’s equipment in the database was especially helpful for my next big feature: Local AI Training Template generation.

To be honest, I initially wanted to use the MCP server I had programmed earlier for this task. But by the time I got to implementing the AI feature, I realized that Ollama doesn’t actually support MCP natively because it lacks an MCP client.

So, I built an Agentic loop directly in my NestJS backend to act as a middleman between Ollama and my server. I could have gone the route of calling my MCP server through my backend and called it a day. But after a short “question battle” with Claude Code, I decided that wasn’t feasible due to the unnecessary network requests I could save by just implementing the agent loop directly in the backend.

My custom MCP Server now exists on its own and isn’t connected to anything just yet. But building it was a fantastic learning experience regarding how these systems work. It lays the groundwork for future implementations, as I eventually plan to integrate external MCP-capable AI tools like Claude or ChatGPT.

Technical Deep Dive: Gymetrics Feature List

For those interested in the exact tech stack and architectural decisions, here is a breakdown of what’s running under the hood:

The Stack

• Frontend: Kotlin Multiplatform, Compose Multiplatform (Shared UI), targeting Android (first priority) and iOS.
• Backend: Self-hosted NestJS API with Dockerized microservices.
• Auth: Short-lived Bearer tokens + Refresh tokens.

Core Implementations

• Ktor Client & Auto-Refresh: Centralized HTTP client handling JSON serialization, timeouts, and dynamic base URLs. Used the Ktor Auth plugin to automatically attach tokens and trigger a silent refresh route (POST /auth/refresh) on 401 errors.
• Offline-First Capabilities: Built a custom ConnectivityObserver that tracks network state app-wide. The app displays an offline badge in the TopBar and handles offline Auth checks by optimistically trusting the securely stored token.
• App-Wide Theming: Implemented a custom GymetricsTheme wrapper around MaterialTheme, featuring a sleek, app-wide dark mode and adaptive Android icons.
• State Management & DI: Strict MVVM architecture. State is handled via sealed interfaces and exhaustive when statements (Idle/Loading/Success/Error). Dependency Injection is handled entirely by Koin (using appModule, single, and viewModelOf).

It’s been a massive journey from a simple Ionic prototype to a fully-fledged, offline-capable KMP application with agentic AI workflows. It started as a way to replace a spreadsheet, but it taught me modern mobile architecture, backend, and how to effectively wrangle AI coding assistants.

The post Gymetrics: A Self-Hostable Fitness App with Kotlin Multiplatform, NestJS, and Dockerization appeared first on Mobile USTP MKL.

1. Introduction

When developing an application the developer doesn’t want to repeat the process or creating a user, then listing a product, sending messages, and so on just to be able to test a new feature they are working on. Manually creating records in the database wastes time especially if it has to be done frequently. A seed script solves this issue so the developer doesn’t have to start from zero every time. How ever seeds can also hinder development if it gets bloated with testing every single scenario possible with potential technical non-realistic naming, missing fields and placeholders. What should a useful development seed actually contain?

2. Seed data and test data serve different purposes

First of all, database seeding means to populate a database with initial records after its structure has been created (Supabase). Seeds may include reference data like roles, categories, or settings. It provides a constant and reproduceable sample dataset for development. I can also provide a prepared environment to conduct specific tests. This blog post differentiates two main use cases for seed data.

Development Demo Data
First development demo data’s aim is to produce a regular environment for manual use of the application. It makes the application understandable and useable out of the box. These are really only used in local development to hep with developing or demonstrating features.

Test Fixtures
These are created for specific scenarios that are aimed at smaller parts of the application. The seed data contains only the required states for the given test. This isolates areas of the application and uses less time and processing power because its meant to be dropped often (playwright).

3. Properties of useful development seed data

How unrealistic seed data hurts development
The realism behind the data that is seeded into the database has high significance when finalizing or demonstrating features. Technical labels and placeholders can make or break the UI. A poor seed can create presentation problems, development, and usability problems. To try and avoid these watch out for the following properties.

a. Believable visible content
Names, titles and descriptions are all textual information that need to look natural and follow the application. Other data such as prices with currencies and dates should be reasonable. Images also play a major role and are not an easy thing to make realistic. Finally one of the most important factor is not to use user-facing fields for storing developer notes or technical naming.

b. Relationships
Filling out the table row by row is not best practice to make the data look realistic. A solution for this is to create a few users and create connected records around a few scenarios demonstrating complete workflows.

c. Representativeness
Make sure that all major features of the application are represented in the seed data. This doesn’t have to cover every single possibility, but allow the developer to see functioning features.

d. Safe information
One might ask why not just use production data if available? There are many cases where that is the solution to diagnose a bug for build a highly specific feature. The issue is the handling of personal information. Ideally when using production data a different script should be used to anonymize the data. Even if that is the case real data has to be used with extra care and may add difficulty and require more time when developing, hence the safest option is to use invented but realistic looking data.

4. Conclusion

I decided to choose this topic because i encountered database seeding in multiple development environments before and I have always thought that I would do it a bit differently. Then I started my own project that had seeding for the first time fully controlled by myself. I experienced both ends of the scale either putting too many scenarios and potential edge cases in the seed data or lacking the ability to instantly test some feature. Finally I believe multiple seeding scripts are ideal and a middle point has to be found between maintenance requirement and usefulness due to the size some seeds can grow to.

References

https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/seeding

https://supabase.com/docs/guides/local-development/seeding-your-database

https://playwright.dev/docs/test-fixtures

The post Seed Data Is Not Test Data: Building a Realistic Development Database appeared first on Mobile USTP MKL.

Rev Match Market is a used car marketplace lead by the left right swiping mechanism for marking interest in used car postings and connecting buyers with sellers. This blog post describes the second phase of development that took place on this project. Initially a MVP was made in the 1st phase that already contained the following features: authenticated sessions, swipe-based discovery, favorites, and seller listing management. For further reading about the 1st phase find the previous blog post here.

As a continuation to the initial MVP, the 2nd phase’s main goal was to introduce buyer-seller communication within the application aided with a notification system informing buyers and sellers about new interactions from each other. Another goal was to significantly improve the mobile experience and expand the capability of the UI from a single mobile view to a responsively transitioning UI that supports desktop, tablet, and mobile. Additional goals were the implementation of a concrete sold state that could later be the starting point of KPI tracking. Finally, to be able to later experiment with the app as a real business the application structure and code quality was to be made more production-ready.

2. From Phase 1 MVP to Phase 2 – The Plan

The starting point of the 2nd phase was directly from where phase 1 and the last blog post left off.

• Authenticated marketplace.
• Seller listing creation, editing and soft deletion.
• Swipe-based discovery with LIKE and PASS.
• Favorites and basic make/model/price filtering.
• Nuxt, NestJS, PostgreSQL and Prisma foundation.

The features implemented by phase 2 in order of priority.

• Mobile-first redesign before implementing major new screens.
• Chat and in-app notifications as the main new product features.
• Improved marketplace filtering and incremental feed loading.
• Cleaner domain boundaries, response contracts and privacy handling.

The result speak for them self, even if at this point of the blog only visually.

3. The Mobile-First Interface

Shared Application Shell
The shell places the screens in a wrapping element which provides consistent navigation throughout the navigation between pages and also provides a responsive layout. The components and visual primitives used in the application are also standardized across the different pages including spacing, typography and interaction states. This meant that many components from phase 1 have been completely replaced with special care so no parallel or redundant designs would have to be maintained.

Screen Changes and Account Identity
To start off at the beginning of users journey the login and registration pages have been completely redesigned and made responsive, along with the swipe, car-detail, favorites and seller-listing screens. A visible addition to the users was also made by displaying a name for user facing identity. The user identity also gained increased protection, since emails and user IDs of other users are no longer reaching the frontend other than public contact information on car-detail pages.

4. Improving Marketplace Discovery

A task originally coming from phase 1 has been implemented and improved, which is pagination and filtering of the queue of cars on the swipe page. First of all Filtering did already exist but it is now moved from the frontend to the backend. The number of filters remains small though now its way easier to expand. The front end now only holds a limited number of cars that come next and before the queue is exhausted the prefetching of new cars occurs. Pass decisions still expire and listings return to the queue later.

5. Communication (Chat), Notifications and Sale Lifecycle

This section is arguably the most important for phase 2. This encapsulates Likes creating conversations, the chat experience between buyer and seller, in-app notifications, and a new state for listings “SOLD”.

LIKEs and conversations
As one can know from phase 1 when a user likes a listing, the listing appears in the users favorites tab. Now following that the seller also receives a notification of a potential buyer who liked their listing. To avoid the creation of empty conversations a like in it self doesn’t create a new conversation. Following the like both parties get the chance to initiate a conversation. The seller can initiate from the notification they receive and the buyer can start a chat from the favorites tab or the car-detail page. Either way a new conversation is created when the first message is sent. There can only be one conversation per car and interested buyer.

Chat experience
Chats appear in a list like page which provides basic information to the user about all the chats like total number of unread messages and about individual list items representing a single chat like the last message, the time it was sent and the car that is the subject of the conversation. Chats can still be reached following a successful sale or if a buyer decided to withdraw interest. When a listing is deleted the chat is still readable but new messages are blocked.

In-app Notifications
The two sources of notifications are the Likes and messages. When the application is open and the user receives a notification an in-app popup appears temporarily. In case the user misses the popup, they might still access the notifications in their inbox with a list view. The notification inbox list view similarly to the chat shows notification contents, read or unread states and a counter for all unread notifications. The user can mark only one notification or all at the same time as read.

Sold Listing
The listings can be marked as sold only by the seller. They can do this either from the listing itself or the conversation which will associate the conversation with the successful sale. Sold listings can’t be found on the swipe page anymore and buyers may no longer start new conversations about the sold listings. Within favorites or existing conversations, the listing shows up as sold.

6. Technical Foundation and Data Model

• RevMatchMarket still uses Nuxt 4 for the frontend, NestJS for the backend, and PostgreSQL with Prisma ORM for the database.
• New persistence models that were added in phase 2 are conversations, messages, notifications, and sold state.
• A major change is the increased privacy meaning that response DTOs no longer expose account email and userID.
• The development process was also improved between phases 1 and 2 by using dedicated git feature branches merged into develop and later charry picking from develop to main (production).

7. Challenges and Lessons Learned

The first challenge was to plan the chat and notification system before implementation, what I learned is that it is significantly easier if the process is visualized beforehand using one of many flow chat methods. I also learned about the effort required to produce production grade code, where edge cases have to be treated with special care. I have learnt about several new techniques listed below.

Cursor Pagination
Pagination is used when requesting batches of a long list of data from the API. Cursor pagination loads the next group of records relative to the last record already received. This differs from the more simple offset pagination which requests by skipping x amount of records from the start. A cursor marks the last record loaded by a deterministic value in most cases a timestamp and the record’s id. This is used on RevMatchMarket’s swipe feed, and notification and chat inbox for example to avoid duplicate or skipped records.

Client-side Reconciliation
Reconciliation is to be understood as checking back with the API new data based on the data the browser already had. This process merges new server data with the existing state of the browser. This technique is important mainly because the application uses polling to fetch new messages or notifications. In case a notification is deleted and at the same time the polling occurs the deleted notification may appear again because the polling happened before the delete went through. When new server data arrives it is merged with the browser data by comparing IDs and the newer updatedAt wins over the older one.

Prefetching
The swipe page uses prefetching to achieve a continues feed. When only 3 cars remain from the previous batch of 20 a newer batch is fetched. To have a fluid swipe feed additional steps are also taken to filter out duplicates, potentially successful swipes can’t be re-introduced again, and account and filter changes are watched.

8. Results

The development in the 2nd phase yielded the following results: a completely reworked design and application structure, the ability for buyers and sellers to connect within the application after a potential buyer liked a listing, a notification system to keep buyers and sellers up to date with liked and owned listings, and finally a revised discovery logic that is more reliable and scalable.

The post RevMatchMarket Phase 2 – From Swipe-Based Browsing to Buyer-Seller Communication appeared first on Mobile USTP MKL.