Before you start a project,
find your answers first.

We can start at any stage: when you have only an idea, when you are defining requirements, or when you are reviewing an existing request for proposal or planning document. In the initial consultation, we look at how you operate today and the problems you want to change, and outline the research needed and the priorities with you.

We review your existing screens and features, content structure, operating practices, and connected systems, and separate what can be reused from what needs to be redesigned. If the core problem lies in a specific flow, we may propose partial improvements; if structural limits run across several areas, we may propose a phased full overhaul.

Based on business impact and technical dependencies, we can divide screens, features, data, and integrations into units of transition. While the existing system keeps running, we connect new features through an API (the connection point systems use to exchange data), and together we design an approach that moves each area over once it has been verified, along with check criteria for each stage.

It helps us define the scope if you tell us your goals, the screens and features you need, the types of users, any integration with existing systems, whether data needs to be migrated, and how you want it operated. We propose a schedule and cost after we review this information and agree with you on priorities, the verification scope, and deliverables.

When you select “Send inquiry” on the inquiry form, your inquiry is received right away, sent to the person in charge by email, and kept as an inquiry record. If it can’t be received, follow the on-screen instructions to contact us with an email draft or by phone.

We first check the API (the connection point for exchanging data) that the target system provides, its database access conditions, authentication method, and call limits. For older systems, a relay API or batch processing (collecting data and processing it all at once at a set time) may be a better fit than a direct connection, and we decide the integration structure based on the actual environment and the policies of the organization in charge.

We can cover everything from service planning, where we define user roles and workflows, to information architecture, screen design, visual design, and responsive implementation. If you have an internal plan or design system, we can also work from it and take on only the areas you need.

Depending on the scope, we prepare items such as requirements, screen flows, UI design, system architecture, API definitions, source code, test results, and operating guides. The deliverables you need, their format, and the level of detail are agreed before the project starts, and they may vary with the nature of the project.

We set the migration scope after checking the structure and quality of the source data, the target system’s data model, and the policies for personal information and retention. We first confirm conversion rules and verification criteria using sample data, and include error handling and the timing of the transition in the plan.

We separate different kinds of work, such as warranty fixes, incident response, routine checks, and feature improvements, and agree with you on the operations scope you need. We then confirm the target systems, response times, deployment procedures, staff roles, and how requests are handled, and document them as a separate maintenance scope.

We look at web standards, web accessibility, and whether screens look the same across browsers (cross-browser compatibility) from the planning stage. If the project has accessibility standards to apply, we set the check items for each stage and the acceptance method with you, in line with the requirements.

We agree with you on how to respond when we define the maintenance scope. In that discussion, we classify incidents into severity levels by their impact on the service, set the first response, recovery targets, reporting method, and after-hours contact path for each level, and record them in the operations documents.

First, we define the decisions the dashboard will support and who will look at it, how each metric is calculated and its reference date, and the data sources and refresh cycles. Once the metric definitions are agreed, we lay out the screens in the order people ask questions, moving from summary to detail.

We look at how often the work repeats, the form of the input data, the criteria for checking expected results, exceptions, and the points where people make judgments. We first pick a small task whose effect is easy to check, and separate what AI will handle from what existing rules will handle.

RAG searches internal documents related to the question and gives their content to the language model as context for its answer. We can design it to show the sources, such as document names and relevant passages, alongside the answer. We also define how answers are limited when the search finds no relevant content, and a procedure for the person in charge to check them.

Checking the fit for your work requires a representative sample, but you don’t need to provide all your data from the start. We first check data ownership, usage rights, and whether sensitive information is included, then consider de-identifying the data or using substitute samples.

Using limited work and data, we check whether the model can produce the results you need, whether staff can easily review and correct the results, and what constraints apply to integration with existing systems. We set the evaluation questions and criteria first, and use the results to decide whether to scale up, refine, or stop.

Instead of using AI results directly as final values, we add sources, confidence conditions, exception flags, and human review steps to match how critical the work is. During operations, we keep a history of corrections and failures, and manage recurring errors as improvement items for the data, search rules, prompts (the instructions given to AI), and workflows.

We decide this with you before adoption. We check which environment will store documents and question-and-answer logs; if an external language model is used, what information is passed to it and how much; whether personal information and sensitive material are masked or removed before they are passed on; and who can view the logs and for how long. We record the agreed standards in the design documents and review them again when operating policies change.

We decide this with you before adoption. We agree with your organization’s privacy team on the purpose and scope of recording, how people are notified, how long the original video and analysis results are kept, and who can view them, in line with applicable laws and regulations and your internal policies. We also consider setups that reduce the information handled, such as keeping only the aggregated results needed for the purpose or masking faces on screen.

We have carried out system integration (SI) projects for central government ministries and public institutions. We have developed websites used by citizens and business systems for institutions, such as a public outreach website on a private-sector cloud, an integrated settlement and payment system for a public corporation, the main website for a district government, and digital reading room software for public libraries. To protect our clients, we don’t disclose organization names or figures.

We build screens, business processing servers, and databases with standard technologies that are well established in the public sector and in enterprises. We choose them based on whether maintenance staff are easy to find and whether systems built on them can run for a long time, and we specify the exact setup in our proposal after checking your existing systems and operating environment.

In a message exchange system for card and insurance companies, we implemented secure communication, data encryption, transmission monitoring, and log management. In a settlement system that connects payment terminals with a VAN (the value-added network that relays card payment approvals), we ran web vulnerability assessments to reduce personal information risks and strengthen security. In new projects too, we set standards for permissions, data protection, and logs with you at the design stage.