Digital Cognitive Test App

1. About the Client

• Name: NEWTECH MIND Co., Ltd.
• Industry: Cognitive testing and cognitive health management services
• Assets held: Three patented cognitive tests
• Task: Move the test assets it holds into an app and expand them into a service that continues through to management after the test

We were responsible for full-stack development, including the app, the server, the operations admin system, and the partner business channel.

2. Background

Cognitive testing has long depended on paper and face-to-face administration. An examiner sits beside the person, reads out the items, records the responses, and produces a score by checking them against a scoring table. The person being tested has to fit a time and place, and even after receiving the result sheet, it is hard to interpret the meaning of the numbers on their own.

What comes after the test is empty

The bigger problem comes after the test. Not many people holding a result sheet get an answer to "So what should I do?" The test ends as a one-time event, and the period until the next test is empty. The same is true for the testing organization. With no way of knowing what state a person is in after completing a test, follow-up management cannot be designed.

Connecting testing through to care

Together with NEWTECH MIND Co., Ltd., we moved this entire process to digital from June to December 2025. The three patented cognitive tests were redesigned in game form to lower the barrier to entry, and test results are analyzed by AI and visualized as more than 60 indicators. On top of this, we added AI counseling, sound care, and cognitive training content as features that fill the period after the test. We were responsible for full-stack development, including the app, the admin system, and the server.

In short, there were three goals: make the test easy, make the results understandable, and make what comes after the test continue.

The three goals are intertwined. When the test becomes easier, the number of tests increases, and when the number increases, comparison across points in time becomes possible and the meaning of the results becomes clear. When the results are clear, there is a basis for suggesting what to do next, and the record of following that suggestion is used in turn to interpret the next test. So instead of building features one by one in isolation, we designed a single flow that runs from testing to care.

Technically, the constraint on the initial design was that three kinds of users had to be handled in one system: general users who take the test, administrators who operate the service, and partner businesses that offer the test to their own customers. The three users had to see the same data, but with different visible scope and different permissions to act.

In one line The goals were to make the test easy, make the results understandable, and make what comes after the test continue.

3. Key Features

We built a mobile service for general users, an admin system for operators, and a channel for partner businesses within a single service. The three channels use the same database, while access permissions and screens are separated.

User channel

Users take the test on mobile and receive a result report. The report can be viewed directly on screen or saved as a PDF. After the test, users use AI counseling conversations, sound-based care, and cognitive training content, and these features are provided through subscriptions and passes.

Test history is stored per session. One test becomes a session, with the individual results and analysis attached to it. When the same person takes the test several times, sessions accumulate, so comparison across points in time is possible. A test stopped partway is also distinguished by session status, so it can be continued next time or restarted from the beginning.

Carrying over the scoring criteria the testing organization had been using was not simple either. In paper tests, there were parts where the examiner looked at the situation and made a judgment, but in digital form that judgment has to be stated explicitly as rules. Hard-coding the criteria would require a deployment every time they were reviewed, so the values used for judgment were separated out as data as far as possible.

Operator channel

Operators manage customer status, test results, orders and payments, notices, and content on the admin screens. In the analytics dashboard, they check accumulated test data by indicator and download the data they need as Excel files. Revenue analysis is kept as a separate area and provides aggregation by period.

Daily statistics are not calculated on every query but are accumulated in advance in an aggregate table. Real-time aggregation slows down as test and payment data accumulate, so values are calculated in advance per day and the dashboard reads those values.

Partner business channel

We set up a separate channel for businesses that offer tests and content to their own customers. A business checks the customers and test results that belong to it and manages its sound content lineup. Revenue generated is managed separately as settlement data, so operators can check the settlement status of each business.

Screen structure

User screens are arranged along two axes: testing and care. The first screen shows the tests to take and recent results, and when a test is completed the user moves straight to the report. Care content linked to the results is placed at the bottom of the report, so that the flow of checking the results leads directly to the next action. In addition, counseling, sound, training, subscription and payment, notifications, and profile each exist as their own area.

Admin screens are a repetition of list and detail. Customers, test results, orders, content, and notices are all provided as tables of the same form, with filtering, sorting, and Excel export supported in common. We made the table component shared so that operators do not have to learn a different way of working on each screen. Analytics and revenue are built around indicator cards and charts rather than tables.

The business screens are a reduced version of the admin screens. They use the same components but limit the query scope to the customers that belong to the business, and they exclude features that affect the whole service, such as operating settings.

Content management

How content is structured is directly tied to how it is sold. The data required differs depending on whether a file is sold individually, sold as a bundle, or opened for a fixed period. To keep all three options open, we separated content, bundles, and usage rights.

Sound content is structured with tags and packages rather than as a simple file list. Each piece of content is tagged, tags are grouped to make a package, and purchasing or subscribing to a package creates the usage right. What the user actually listened to and for how long is kept as playback history, and effect analysis and playback pattern analysis are performed based on this history.

How the work proceeded

Over seven months, we widened the scope in the order of testing, care, and payment. We first completed the test and the result report to confirm the core of the service, and then added counseling and sound care. Payment and settlement were added after the earlier features had settled in. This is because a payment structure can only be designed once it has been decided which features are sold in which units.

The admin screens were built together with each feature as it was completed. If only user features are built first and management tools are added later, the team ends up opening the database directly to check things throughout the development period. Building features and management screens on the same cycle turned out to be faster.

Main features

Three gamified cognitive tests

We implemented the three patented cognitive tests in game form. Instead of reading items and choosing answers, the tests were changed into tasks performed on screen, so that people can take part without feeling that they are being tested. Because response time and performance patterns are recorded along with the responses themselves, information that is not visible from correctness alone can also be used in the analysis. During the test, the remaining tasks and time are displayed so that users can gauge the overall length.

Result report based on AI analysis

AI analyzes the collected response data and organizes it into more than 60 indicators. Results are not presented as raw scores alone; they are shown together with classification by domain and by level, with a summary sentence added. Because the report is generated as a document rather than a screen capture, it can be downloaded as a PDF to keep or pass on. Analysis requests and responses are logged so that it can be traced when different results come out for the same data.

AI counseling and credit management

Conversational counseling is provided based on the test results. Text counseling and sound-based counseling are supported separately, and conversations are stored per session. Usage is managed with credits, and the amount available is adjusted according to the subscription tier. The prompts that determine the tone and scope of counseling are not fixed in code but separated out as configuration data. This is because there was a requirement that it must be possible to adjust them without a deployment when the counseling criteria change.

Sound care and effect analysis

Sound content is assigned to users, and playback history is stored. This history is used to analyze which content was played and how much, and at which times of day playback is concentrated. Because usage data is kept rather than stopping at providing content, there is a basis for reviewing the effect later. Assignment supports both individual designation and provision by package.

Subscription payment and recurring billing

Toss Payments is integrated to handle card registration, subscription payment, recurring billing, and refunds. Payment method registration and billing key management are separated so that a payment failure does not lead straight to cancellation of the subscription. Passes are issued by type, and order status and payment status are managed as separate values. This is to distinguish and handle the situation where payment succeeded but granting the pass failed.

Test history comparison

When the same person takes the test several times, sessions accumulate. On the history screen, results from different points in time can be viewed side by side, so what is visible is the direction of change rather than a single score. Because the trend over time carries more information about cognitive status than the absolute value at a single point, we designed storage to be per session from the start.

Notifications and notices

Push notifications and email are used together. System notifications and customer-facing notifications are stored separately, and notices are managed in a separate area. Because notification types are kept apart, marketing notifications and notifications related to tests and payments can be sent under different criteria.

Exporting operating data

The main lists on the admin screens can be downloaded as Excel files. This is because the screen alone is not enough when test results are passed to an external organization or used for in-house analysis. Reports are provided as PDF and list data as Excel.

Cognitive training content

Training content is provided that users can go on to after checking their test results. Because it is task-based in the same way as the tests, users do not have to learn separately how to use it. Training records are also kept as activity data and can be viewed together with the test history.

Customer activity records

Meaningful actions such as login, starting and completing a test, content playback, and payment are kept as activity data. These records can be viewed in chronological order on the customer detail screen. When an inquiry comes in, "what was done and when" can be checked without asking the customer again, and the records are also used to identify drop-off points.

Key design decision We kept testing, content, and payment as independent branches and connected them through the customer. Even when the policy of one area changes, the structure of the other areas is left untouched.

4. Outcome

We completed a service that moves the three patented cognitive tests into game form and visualizes test results as more than 60 AI analysis indicators. By moving tests that were tied to paper and face-to-face administration onto mobile, the constraints on when and where a test can be taken disappeared.

What characterizes this project is that the features filling the period after the test were built along with it. AI counseling, sound care, and cognitive training are connected to the test results, so users do not stop at receiving a result sheet but move on to the next action. Because playback history and activity records are kept, operators can also check the state of users after the test.

Increasing the indicators to more than 60 was also intentional. With few indicators, a person ends up being defined by a single score, and the whole result looks different when that score shifts even slightly. Dividing domains and breaking the indicators down shows which parts are strong and which are weak, so the result can be read as a state rather than a grade.

On the operations side, testing, analysis, counseling, payment, and settlement are handled within a single service. Operators manage customers, test data, and revenue in one place on the admin screens without moving between separate systems, and partner businesses see data only within the scope of their own customers.

In terms of data structure, keeping testing, content, and payment as independent branches and connecting them through the customer worked in favor of later expansion. Adding test types does not touch the payment structure, and changing the sales unit does not require modifying the test logic. In a service where features keep being added, this boundary determines development speed.

Because it was designed as a service for continuing to manage cognitive health rather than one where the test itself is the goal, it can be extended on the same structure even when test types increase or care content is added later.

Over about seven months from June to December 2025, we built the app, the server, the admin system, and the business channel in full.

5. Technical Stack

Web / Mobile

Built with Next.js App Router, React, and TypeScript. The user mobile screens, admin screens, and business screens are divided into route groups within a single codebase. The UI is built with Tailwind CSS and Radix UI-based components, and charts use Tremor and Recharts together. Internationalization is handled with next-intl and i18next.

AI

The OpenAI API is integrated to handle analysis and counseling. Prompts are managed separately as configuration data, and requests and responses are logged. Because analysis results are stored linked to the test session, it is possible to check which analysis was performed for the same test and when.

Backend

Domain APIs are built on Next.js API Routes. The database is Prisma ORM and PostgreSQL, and authentication uses NextAuth.js. Files are stored in AWS S3 and accessed through presigned URLs. Images, audio, and downloads go through separate proxy routes so that the storage address is not exposed to the client as is. Periodic jobs are split into separate routes that the scheduler calls.

Payment / Notifications

We use the Toss Payments payment and billing SDKs, Firebase Admin push notifications, and Nodemailer for sending email. Payment is implemented with the one-time payment flow and the recurring billing flow separated.

Documents / Data

Report PDFs are generated with jsPDF and html2canvas, documents are parsed with pdf-parse, and data is exported with xlsx. Markdown rendering is supported so that formatted text generated by AI is displayed as is.

Permission separation

Because the three channels use the same database, checking the query scope individually throughout the code means it will be missed somewhere eventually. User roles are managed as data, and the relationship of customers belonging to a business is stated explicitly in the data model so that the scope is narrowed automatically at query time. This restricts data access itself rather than hiding screens.

Data model

The model has five main branches: users and customers; testing (sessions, results, analysis); content (sound, tags, packages, assignment, playback history); payment (orders, passes, subscriptions, settlement); and operations (statistics, activity, notifications, notices). Because testing, content, and payment are each kept as independent branches and connected through the customer, the structure of the other areas is left untouched even when the policy of one area changes.

Problems addressed during implementation

Reliability of test data. In game-style tests, there are situations where the user leaves the screen or switches apps. In such cases, response time is recorded as a value unrelated to actual performance. This is why we put a status on the test session to distinguish interruption from completion and decided how data from interrupted sessions is treated in the analysis.

Variation in AI responses. Even with the same input, the generated result differs slightly each time. Analysis requests and responses are logged so that a problematic result can be checked later. Separating prompts out as configuration data follows the same reasoning. If a deployment procedure has to be followed just to fix the wording, the improvement cycle is tied to the deployment cycle.

Separating payment from granting rights. Payment success and granting a pass are different events. If they are bundled into one operation, the state where payment went through but the right is missing cannot be explained. Order status and payment status are kept separately, and the service is configured so that a recurring billing failure does not lead to immediate cancellation.

Media file access. If sound and report images are exposed directly by storage address, anyone who knows the link can access them. We route access through a proxy route so that the file is delivered after permission is checked.

Statistics query speed. As test and payment data accumulate, dashboard queries slow down. We set up a daily aggregate table and calculate it in advance with a periodic job, so that the screen reads only aggregated values.

6. Project Information

Item	Details
Project name	Development of a digital cognitive test app (AI, 60+ indicators)
Scope of work	Full-stack development (app, server, admin, business channel)
Technologies	Next.js, React, TypeScript, Prisma, PostgreSQL, OpenAI API, AWS S3, Toss Payments, Firebase