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.

This blog will show: What it is, why it’s popular, what can go wrong, and a checklist for safely.

What Is “Vibe Coding

“Vibe coding” is programming using natural language. AI generates the code and the developer iterates based on the results. In this approach. “the coder does not need to understand how or why the code works” (Merriam-Webster, 2025) The term became mainstream in 2025 and is now widely used to describe building software by prompting AI and iterating quickly, often with minimal manual code review.

Instead of understanding code, developers when vibe coding focus on a simple question
“Does it work?”

Traditional coding focuses on understanding, structure, and design, while vibe coding focuses on speed, iteration, and end-result.

The Vibe Coding Loop

Vibe coding typically follows a simple loop:

1. Describe feature in natural language
2. AI generates code
3. Run it and test it
4. paste errors back
5. Fix and repeat

This loop further emphasizes the speed of iteration vibe coding allows its users. Results are produced faster and the developer can focus more on refinement of the results or extending features.

Why People Love It: Speed

The biggest reason developers vibe code is speed.
As they say time equals money. AI assistants can greatly reduce task completion time. Its been measured that developers using GitHub Copilot finished a coding task ~55.8% faster
(Peng et al., 2023). Naturally this number can change depending on the scenario but it clearly shows that Ai assistance accelerates implementation.

Reality Check: “Looks Right” ≠ “Is Right”

Results can be misleading, just because code looks correct does not mean it actually is correct. The more “long-term maintenance” and “high stakes,” the more we must shift from vibes to verification. A well known phenomenon hallucination can occur in AI-generated code. While the code can be syntactically correct it can contain factual inaccuracy. ” (Alansari & Luqman, 2025)

Bugs may also be subtle:

• Edge cases may not be handled
• Race conditions may exist
• Wrong assumptions may be built into the logic
• Maintenance becomes risky if nobody understands the code later

This leads to systems that work initially but become fragile and difficult to maintain.

Real-World Security Risks

Often AI-generated code contain serious vulnerabilities for example: Data exfiltration (exportation), unsafe actions by AI agents injecting instructions.

Schreiber & Tippe (2025) — Analysed 7,703 AI-generated files and found thousands of CWE-mapped vulnerabilities.
Sabra, Schmitt & Tyler (2025) — SonarQube analysis showed hard-coded credentials and other severe issues even when unit tests passed. SonarQube is a tool for Static Code Analysis for all languages.
Tihanyi et al. (2024) — Large-scale model study found ~62% of generated code was insecure by formal verification. This formal verification is done through Efficient SMT-based Context-Bounded Model Checker (ESBMC).
Fu et al. (2025) — Copilot and similar assistants produced code with ~24–30% serious Common Weakness Enumeration (CWE) security flaws across languages.

Even if your own code is fine, your tooling and agent workflow can be the attack surface especially when the AI has “powers” (terminal access, file writes, network).

Security Risks in Vibe Coding

Prompt Injection

LLM app guard rails can be manipulated by prompt injection. OWASP lists prompt injection as a top LLM app risk category (OWASP, 2024). UK NCSC warns prompt injection is not like SQLi and may be harder to fully “fix” with a single mitigation (UK National Cyber Security Centre (NCSC), 2025).

Insecure Code Generation

LLMs may generate code with known vulnerabilities Prone to insecure code, but can improve with feedback/hints (Yan et al., 2025)

Guardrails: How to Vibe Code Responsibly

Vibe coding can be powerful but only with proper guardrails.
Responsible use should include:

• Generate tests first
• Force model to justify by explanations
• Use linters + type checking
• Prompt “avoid CWE top issues; use safe defaults”
• Never let an agent run with broad permissions by default
• Code review: auth, input validation, file/network access

Using AI-assisted development should be done with taking the necessary precautions. Keep a fast loop but add verification gates. Effort from  typing code to validating it.

Takeaways

Vibe coding is a new way to code that is becoming more and more standardised. It is fast, iterative, and AI-driven. It helps in rapid development and experimentation, but it also introduces risks in quality, security, and long-term maintainability.

Used responsibly, vibe coding can be a powerful tool in modern development. Without guardrails, it can quickly become hidden tech-debt and security issues.

References

Alansari, A., & Luqman, H. (2025). Large Language Models Hallucination: A Comprehensive Survey (No. arXiv:2510.06265). arXiv. https://doi.org/10.48550/arXiv.2510.06265

Collins Dictionary. (2025). Collins—The Collins Word of the Year 2025 is… https://www.collinsdictionary.com/woty

Fu, Y., Liang, P., Tahir, A., Li, Z., Shahin, M., Yu, J., & Chen, J. (2025). Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study (No. arXiv:2310.02059). arXiv. https://doi.org/10.48550/arXiv.2310.02059

Merriam-Webster. (2025). Vibe coding. https://www.merriam-webster.com/slang/vibe-coding

OWASP. (2024, 2025). LLMRisks Archive. OWASP Gen AI Security Project. https://genai.owasp.org/llm-top-10/

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (No. arXiv:2302.06590). arXiv. https://doi.org/10.48550/arXiv.2302.06590

Sabra, A., Schmitt, O., & Tyler, J. (2025). Assessing the Quality and Security of AI-Generated Code: A Quantitative Analysis (No. arXiv:2508.14727). arXiv. https://doi.org/10.48550/arXiv.2508.14727

Schreiber, M., & Tippe, P. (2026). Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories (Vol. 16219, pp. 153–172). https://doi.org/10.1007/978-981-95-3537-8_9

Tihanyi, N., Bisztray, T., Ferrag, M. A., Jain, R., & Cordeiro, L. (2024). How secure is AI-generated code: A large-scale comparison of large language models. Empirical Software Engineering, 30. https://doi.org/10.1007/s10664-024-10590-1

UK National Cyber Security Centre (NCSC). (2025). Prompt injection is not SQL injection (it may be worse). https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection

Yan, H., Vaidya, S. S., Zhang, X., & Yao, Z. (2025). Guiding AI to Fix Its Own Flaws: An Empirical Study on LLM-Driven Secure Code Generation (No. arXiv:2506.23034). arXiv. https://doi.org/10.48550/arXiv.2506.23034

The post Vibe Coding: Fast AI-Driven Development — Benefits, Risks, and Guardrails appeared first on Mobile USTP MKL.

The Idea

Buying a used car can be overwhelming. Traditional marketplaces often present users with long, filter-heavy pages filled with static listings. My goal was to improve that experience. The swipe mechanic makes browsing fun.

Objectives and Learning Goals

Three main goals: technical, business, and personal learning.

Technical Objectives

To develop a mobile-web application that demonstrates:

• authentication with protected routes
• creation and management of car listings
• swipe-based browsing
• favorites management
• filtering by make, model, and price
• frontend-backend integration in a structured monorepo
• database-backed persistence for users, listings, images, and swipe decisions

Although the initial plan mentioned Ionic and Angular, the project evolved into using:

• Nuxt 4 for the frontend
• NestJS for the backend API
• PostgreSQL + Prisma ORM for persistence
• Cookie-based JWT authentication for session handling
• Docker for local database infrastructure

This is due to my more dependable previous experience with this stack to build a full-stack monorepo.

Project Scope

MVP

• Mobile-first UI
• User registration and login
• Car listing creation and management
• Swipe-based browsing of cars
• Filtering by make, model, and price
• Favorites page
• Backend-connected database

What the Current MVP Includes

• user registration and login
• cookie-based authenticated sessions
• protected pages for logged-in users
• a swipe feed for browsing available cars
• like and pass actions
• a favorites page for liked cars
• a “My Cars” area for sellers
• car listing creation
• car listing editing
• car listing removal through soft delete
• car detail pages
• optional image upload for listings
• simple client-side filters for make, model, and maximum price

Explicitly Excluded

• Payment processing between users
• Full production-grade infrastructure
• Chat functionality
• Location-based matching
• Analytics systems
• App Store / Play Store deployment

Key Deliverables

The final outcome of RevMatchMarket includes:

1. A working MVP
   A swipe-based used car marketplace where:
   • Sellers can create, Edit, Delete listings
   • Listings have images
   • Buyers can browse cars
   • Users can like or pass listings
   • Users can apply filters to listings
   • Favorites are stored and retrievable
   • Full authentication
2. Documentation
   • Detailed project and milestone planning
   • This blog post summarizing the process and learnings
3. Final Presentation
   • Live demo of the application
   • Reflection on challenges
   • Discussion of future improvements

Challenges and Lessons Learned

Creating a UI for mobile devices required careful consideration. Authentication and protecting routes was required a few iterations. Managing JWT tokens via httpOnly cookies and handling session bootstrapping on the frontend. Features need to be limited. It is tempting to add chat, real-time updates, and other features but keeping the MVP focused was essential.

Diagrams – Database & Flow Chart

Final Thoughts

RevMatchMarket redefines a simple interaction pattern. This project, I strengthened my skills in full-stack development, mobile-first UI design, backend integration, and structured project planning.

This project started as an assignment but it has the can become much more.

The post Rev Match Market – A Swipe-Based Used Car Marketplace appeared first on Mobile USTP MKL.

Abstract

Real-time 2D human pose estimation using smartphone cameras has
become a highly relevant technology for interactive applications
such as physical education, gesture-based interaction, and aug-
mented reality. While recent advances have significantly improved
pose estimation models, using such systems on mobile devices
remains challenging due to computational, energy, and latency con-
straints. This paper presents a state-of-the-art review of real-time
2D pose estimation approaches targeting smartphones, following
a PRISMA inspired systematic literature review. Two recent and
relevant papers, LMFormer and LiPE, are analyzed and compared
based on design choices, efficiency metrics, evaluation scope, and
suitability for mobile and human–computer interaction (HCI) prac-
tical use cases. The review highlights the balancing of accuracy and
computational efficiency, identifies limitations in current evaluation
practices, and outlines open research gaps related to end-to-end
mobile performance and interaction-oriented evaluation criteria.

The post State of the Art in Real-Time 2D Pose Estimation using Smartphones appeared first on Mobile USTP MKL.