What Lies Between Building an App
and Running a Business System

AI has greatly expanded what you can build

Applications that once required a specialist engineer can now, with AI, be implemented in-house to a remarkable degree. This is a genuinely major change.

• Build screens
• Register data
• Search
• Show information on a map
• Assign staff

At the same time, a system your company relies on continuously for its business needs much more than "features that work on screen" — it is surrounded by a large set of design, operations and management concerns.

At the center: the app's features

This is the most visible part. A sales-support app, for example, might have the features below — and this is exactly the area where AI-assisted development brings the biggest gains.

• Map view — place customers on a map
• Search — find customers by name
• Filtering — narrow down by criteria
• Assignment — decide the sales rep in charge
• Visit records — mark customers as visited
• Create & edit — correct customer data
• Admin screen — see the whole picture
• Activity history — who did what

Looking only at this part, concluding "we could build this ourselves" is, today, an entirely reasonable judgment.

The big picture — what surrounds the app's features

What you see on screen is the center — the app's features. Used for real business, the system only becomes whole together with its surroundings.

Not everything around the app needs equal effort, though. You choose depth according to impact × likelihood (see the ladder of criticality at the end of Part 2).

Authentication — knowing who is using the system

The first thing you need is a way to confirm who is actually using this system. Having a login screen is not necessarily enough.

• Per-user ID management
• Password management
• Multi-factor authentication
• Single sign-on (e.g. with LINE WORKS)
• Disabling accounts of departed employees
• Password recovery
• Defenses against unauthorized login
• Login attempt limits
• Session management
• Auto-logout on inactivity

Access control — what each person may see and do

Once someone is logged in, you need to decide what they are shown and what they are allowed to do.

Scope differs by role

Staff, sales reps, sales managers, administrators, executives, system administrators — each role may need different visibility and different permissions.

Examples of finer-grained control

• See only your own customers / only your own branch / the whole company
• Who may edit customer data — and who may delete it
• Who may add users

Data — where to keep it, and how to keep it correct

Deciding where data lives

• Which database to use / whether data stays in-country / whether cloud is acceptable
• How much personal data to store / what may be passed to external services
• Encryption / whether production data may be used in development / preparing test data

Mechanisms that keep data correct

• Preventing duplicate customer records / two people editing at once without losing one side's changes
• Delete and update rules that protect data that must never be lost
• Input validation / CSV imports that don't corrupt existing data

Hard to see on screen — and critically important in a business system.

Can you undo a mistake? — backup and recovery

In real operations, mistakes will happen. For example: "a sales rep accidentally deleted 500 customer records" is a scenario you should expect.

Recovering from operator error

• Can you restore the pre-deletion state? Up to what point in time?
• Can you tell who changed what? Can you restore individual records?

Operations means more than "the delete button works" — it extends to the company being able to recover after a mistake.

Designing and rehearsing backups

• How often to back up / how many days to retain / storing copies away from production
• Can you actually restore? — periodic restore tests, with time taken and problems recorded

"We backed up every day — and spent six months storing broken backups" is a real possibility.

Monitoring and incident handling — designing for failure

Monitoring — the ability to notice

• Are the app, servers and database up?
• Are errors increasing? Is disk space running out?
• Is an external service down? Is there unauthorized access?

This is what prevents "we only learned about the outage when a customer called".

Incident handling — decide in advance

• Who detects, who gets contacted / what happens at night and on weekends
• Response within how many minutes or hours / whether the service may be stopped
• Is the recovery procedure defined? How is the root cause investigated?

Activity history, audit logs and security

Recording who did what, and when

• Who logged in / who viewed customer data
• Who changed what (values before and after) / who deleted what
• Who changed administrator privileges

Think through retention periods, logging the administrators' own actions, and tamper-resistance.

Preparing for attacks and accidents

• Unauthorized logins / password brute-forcing / attacks on flaws in screens and APIs
• Permission mistakes / accidental exposure through misconfiguration / leaked API keys
• Continuously updating the OS and libraries and tracking vulnerability disclosures

Performance, and your relationship with external services

Performance — does it still work when things grow?

• Fast with 1,000 customers → search slows down at 100,000
• Stops under 100 concurrent users / map bogs down with too many markers
• Think through expected users, concurrency, data volume, response times and future growth

External services — they change on their terms

External services such as Google Maps, LINE / LINE WORKS, email and SMS, payment providers and cloud platforms come with "their side" of the deal: pricing, usage limits, terms of service, outages, specification changes and login-method changes.

Separate environments, change management and testing

Separating environments

• Separate development, testing and production (touching production directly means one mistake can stop the business)
• Who may deploy to production / which version is live / can you roll back to the previous version

Managing the impact of change

• Adding a single input field can ripple into the database, screens, CSV files, printed forms, permissions, tests and manuals
• Who decides a change, how its impact is verified, and when it reaches production

Scope of testing

• Beyond valid input: invalid input, blanks, very long strings, concurrent operations, dropped connections, unauthorized users, large data volumes
• When adding a feature, does everything that used to work still work? (regression testing)

Records, handover, cost, and how it ends

Recording why it was designed this way

• Architecture, database design, permission design, operating procedures, and the reasons behind key decisions
• Not "we can build it, so no need to write it down" but "it's easy to record now, so keep the record"

What key-person dependency really means

• One person building it is not, by itself, a problem. The problem is a state where nobody else can decide, recover, change or take over without that person
• So that business continues through resignations, transfers and long absences, keep accounts, contracts and source code under company control (it is a business-continuity issue)

Budgeting for ongoing cost

• Monthly costs continue: servers, database, APIs, maps, monitoring, certificates
• As usage grows, consider that ¥10,000/month can become ¥100,000 or ¥500,000

Thinking about the end from the start

• Can you extract your data? Migrate via CSV? Are you locked into a specific service? Can data be fully deleted?
• Think about how it ends at the moment you start building

What AI has changed

None of the above says "so don't build in-house". Quite the opposite. With AI, far more than implementation gets dramatically more efficient: writing design documents, writing tests, security checks, documentation, operational runbooks and code review.

The range of what a company can build in-house will therefore keep expanding. It has also become realistic for one person or a small team to combine roles — design, implementation, testing, security checks, documentation and operations.

"Can't AI just do all of it?" — Yes, a great deal

First of all: that is largely true. Much of implementation, research, documentation and testing is dramatically accelerated by AI — we build that way ourselves. What is worth laying out is the contrast between what AI reduces and what it does not.

What AI reduces

• Implementation effort / research effort
• Documentation and manual-writing effort / test-writing effort
• Headcount required

What AI does not reduce

• Final judgment (deciding what to adopt)
• Responsibility (owning the outcome)
• Approval (deciding a change may go ahead)
• Continuous operation (keeping it running)
• Accountability (explaining to people inside and outside the company)

Not "how many people" but "how many roles are covered"

Three people who can write code are not automatically enough if the roles below are undefined. Conversely, two or three people with these roles genuinely covered make a strong setup. Everything in the "surroundings" so far is a question of roles, not headcount.

• Decides the design
• Watches security
• Runs operations
• Approves changes
• Owns the data
• Explains to stakeholders

AI made combining roles realistic

• The range one person or a small team can cover — design, implementation, testing, security checks, documentation, runbooks — has grown substantially
• You don't need to hire one person per role. A small team can keep the roles covered

You still need to define the roles

• Decide who holds which role and how far they may decide — and write it down
• The more roles are combined, the more deliberately the boundaries need to be drawn (next section)

The pitfalls of combined roles — and the remedies

It easily becomes self-review and self-approval

• When one person plus AI covers development, review, testing and deployment, everything is effectively self-approved
• Using several AIs doesn't change this: if the same person decides what to adopt, the roles are not separated

The remedy: put mutual checks only where they matter

• Not every change needs someone else's approval
• For high-impact changes — customer data, authentication, permissions, the production database, security settings — have someone other than the author check. Decide by impact

The limits show up when everything happens at once

• In normal times, AI keeps things running well. The problem is when an outage, a vulnerability, inquiries, an external-service change and new development all arrive at once
• AI can work in parallel — the person who judges, approves and explains cannot. That is where it jams

You can't ask AI about issues you don't know exist

• AI answers when asked — but you can't ask about an issue you've never heard of. For backups, it's not just "are we taking them" but recovery point objectives, recovery time objectives, restore testing and separated storage
• Expertise is less about knowing answers than knowing what to ask

The question is not "can we build it" but "how do we keep owning it"

In most cases, with AI, you can build it. What you decide is not "outsource or not" — it is where judgment sits and where verification sits.

Judge in-house

• Business rules, feature and improvement priorities, day-to-day operational judgment
• Keep the seat of judgment in your own hands, always

Put third-party verification at the key points

• High-impact changes (customer data, authentication, permissions, production data, security settings) get checked by eyes other than the author's
• Those eyes can be a different person in-house, or external. A separate AI can assist verification, but if the same person decides adoption, there is no separation — so place a different person as the verifier

Use expert support only when expertise is needed

• Surfacing the issues, reviewing designs, an audit perspective
• Not permanently on-site, not full outsourcing — only the moments that need it

The layers further out, for an enterprise system

For a system a company relies on continuously, management extends beyond the app's surroundings into infrastructure, networking, procurement, release, operations, security, audit, documentation, training and vendor management. Not everything needs equal depth — choose according to the system's criticality (the ladder of criticality comes at the end of this part).

* ISMS = a framework for managing information security as an organization (third-party certification schemes exist).

Redundancy, availability and networking

Does one failure stop everything?

• With a single server, a single line or a single database, that one point of failure stops the whole system
• Multiple servers / duplicated database, lines and power
• "It's redundant, so we're fine" is not enough — which failures does it survive, does it fail over automatically, how many minutes does switchover take, has switchover been tested?
• Agree RTO (recovery time objective), RPO (recovery point objective) and acceptable downtime with the business side

Network design

• Redundancy for inter-site links, cloud connectivity and internet access
• Route control (mechanisms such as BGP) — manage what flows where, and how routes switch in a failure

Networks are invisible in daily work — and in a failure they can stop the entire business.

Procurement, vendor management and asset management

Managing procurement and outsourcing

• Approval rules for purchases and contracts / vendor selection criteria / checking SLAs
• Handling of personal data / the country where data is stored / subcontracting / data deletion at contract end
• Tracking end-of-life (EOL) dates / knowing your dependence on specific vendors
• How much access contractors get, evidence of their work, deleting their accounts when engagements end

The asset register — a list of what you use

Servers, cloud accounts, domains, SaaS subscriptions, licenses, certificates, API keys, code repositories, backup targets.

• Know what exists in production, development and staging — and update the register and diagrams when things change

Release management — reaching production safely

AI has made code changes very fast. Which is exactly why the path to production needs clear rules: change → peer review → automated tests → verification in staging → approval → deploy → post-deploy check → roll back if something is wrong. The depth of review and approval scales with the impact of the change.

The deployment method itself is a design decision. In a Blue-Green setup, for example, you run two production tracks: the current one (Blue) keeps serving users while the new version (Green) is verified for behavior and compatibility; only then is traffic switched over — and switched back to Blue if problems appear. Database changes, however, cannot simply be reversed, so the release method itself has to be designed.

Change approval, runbooks and access reviews

Record and approve changes

• Before AI-written fixes go straight to production, put a verification step in the path
• Record the reason, content, impact, test results, approver and rollback plan
• High-impact changes (customer data, authentication, permissions, production data, security settings) are checked by someone other than the author
• Emergency changes are not exempt from recording — they are recorded and reviewed after the fact, without exception

Turn operations into runbooks

• Daily, weekly and monthly checks / backup verification / certificate expiry / first response to incidents / disabling accounts of departed employees, and so on
• Who does what, by which procedure, how far they may decide, and when to escalate

AI speeds up manual-writing — but the operating rules themselves must be decided by the organization.

Account and permission reviews

• Who requests, who approves / when accounts are disabled on departure / reviews on transfer
• Periodically confirm "does this person still need this permission?"
• Beyond having the mechanism, keep records that reviews were carried out

Managing incidents, issues and requests — beyond "fix it when someone complains"

Once the system is in use, bug reports, improvement requests and how-to questions arrive daily. Rather than carrying them in your head or in a chat scroll, collect them in a ticket log — one managed record per item. The flow: intake → triage (bug, request or question) → prioritize → handle → verify → close and record.

One intake point

• User inquiries, observations from the field and monitoring alerts all land in the same log
• Reports received in chat get a ticket before being worked on (so they don't scroll away and vanish)
• Outages that stop the business, and data incidents, don't wait for a ticket — escalate immediately and start the response; record in the log in parallel or afterwards

What each ticket records

• When it happened, what happened, impact, steps to reproduce, severity, priority
• Owner, status (open / in progress / awaiting verification / done), what was done, verification result

Align how priority is decided

• Severity = size of impact; priority = severity × urgency — use shared definitions, and don't make everything top priority (distinct from the impact × likelihood used to set the depth of countermeasures)
• Don't let items sit forgotten — review the backlog regularly

Don't stop at the fix — prevention and a regular cadence

Follow through to prevention

• For high-impact or recurring problems, don't close at "fixed" — dig one level deeper into why it happened (for operator error, consider redesigning the screen to make the error harder to make)
• Check side-by-side whether the same class of problem exists in other screens or other processes
• Feed the lessons back into tests, runbooks and rules

Sharing with users

• Share a list of known unfixed issues and their current workarounds
• When something is fixed, tell the person who reported it (build the loop where reporting makes things better)
• Announce maintenance windows in advance

Run it on a regular cadence

• At a monthly (or similar) regular meeting, report counts, trends, open items and upcoming changes
• Pre-agree response targets by severity (e.g. business-stopping outages get attention the same day)
• Keep the issue list and the record of decisions — meetings fade, the log remains

Scheduled batch processing, and data housekeeping

Behind the screens, scheduled batch jobs run: the morning import, daily aggregation, notifications. This area needs its own design, separate from the screens.

Job design — when, and in what order

• Manage jobs with a scheduler and define their ordering (predecessors and successors)
• Design closing runs, month-end and holiday handling (an execution calendar), and headroom in processing time

Failure design — what happens when it stops

• Failure detection and notification / resumable from mid-point / re-running must not double-count or double-send / prevention of duplicate starts
• Monitoring for overruns past the scheduled end, and a runbook for manual re-runs

File-exchange design — distrust the hand-off

• Agree formats, character encodings and arrival times
• Design for the day the file doesn't arrive or is corrupt: detection, re-send requests, and record-count reconciliation

Data housekeeping — don't just let it pile up

• Set a retention period per data type; archive or delete the old
• Watch log growth, disk usage and data volume, and keep maintaining database performance

Ongoing vulnerability response — weaknesses are found later

Vulnerability assessment (testing)

• After building, test screens, APIs, servers and cloud configuration for weaknesses
• Plan by criticality: before release, after major changes, annually
• Not "assessment done" — findings management → risk evaluation → fixes → re-assessment

Watching vulnerability disclosures

• Weaknesses are discovered later in the OS, components and external services you already use
• Define which sources are watched, by whom, evaluated within how many days, and how fast critical ones are fixed
• Automated alerts (such as dependency update notifications) can help

Patching and end-of-life management

• Patch scope, deadlines, testing, deployment and exception management
• Products past end-of-life (EOL) are replaced on a plan — not kept "because they still run"

Log aggregation, incident response, and disaster preparedness

Aggregating logs and detection

• Aggregate not just app logs, but device, authentication and cloud records
• Detect unauthorized logins, mass downloads and suspicious traffic (SIEM = a mechanism that aggregates logs to find anomalies)
• Manage retention, tamper-protection, read permissions — and clock synchronization across devices (the precondition for correlating records)

Incident response

• Don't rely on on-the-spot judgment: define first response, isolation, evidence preservation and investigation in advance
• Reporting to customers, to management, and as required by law
• Night-and-weekend contact chains, external specialist firms, through to prevention

Disaster preparedness (business continuity planning, BCP)

• Plan for earthquakes, power failures, line cuts, cloud outages and ransomware
• Off-site backups, recovery priorities, alternative means of operating
• Don't stop at a paper plan — rehearse it

Secrets, devices, training, and AI governance

Secrets, keys and certificates

• Don't put API keys and passwords in source code / don't commit them to the code repository
• Manage them in a dedicated store and rotate them / monitor certificate expiry / retire aging cryptography on a plan

Device management

• Disk encryption, screen lock, anti-malware
• Remote wipe when a device is lost / data erasure at disposal

Training and drills

• Security training, phishing drills, administrator training, incident-response drills
• AI usage rules (what may be entered) are part of the curriculum too

AI governance

• Which AI services are permitted / what must never be entered (personal data, credentials, customer data)
• Review of AI-written code / no direct AI changes to production
• License checks and inventory of open-source components brought in — regardless of whether they arrived via AI
• Make explicit what AI may change and what needs human approval
• Decide in advance how to handle AI/model changes and service termination, including where you would migrate

What ISMS and audits look at: mechanism, practice, evidence

What ISMS and audits examine is the cycle: rules (written in policy) → practice (actually done that way) → evidence (records kept) → improvement (reviewed and corrected).

Example: the account review

• The policy says accounts are reviewed every six months
• They actually are reviewed every six months
• The results are retained
• Unneeded accounts are removed
• The removals are recorded

Backups, patching, vulnerability checks, training, permission reviews and incident drills are all managed on the same cycle.

The whole picture outside "the app you can build"

What AI made fast to build is the part in the gold frame. AI is also a powerful aid for organizing and verifying the surrounding layers.

Supplement — further items worth considering

Data migration and parallel running

• When replacing an existing system: how data is migrated and verified
• The parallel-run period, the cutover date, and where data gets entered on cutover day

Law and personal data

• Obligations under personal-data protection law (safeguards, restrictions and records on third-party provision, reporting and notifying individuals after serious leaks)
• Industry-specific regulation, terms of service. Consult specialists where judgment is unclear

User support and adoption

• A help desk, user training, a user manual
• Checking whether it is actually used — without adoption, the expected benefit is hard to realize

Maintenance contracts and where responsibility divides

• How far defect fixes are free (statutory non-conformity liability) / the scope and cost of maintenance
• The contact point, response-time commitments (SLA), return of data at contract end

The ladder of criticality — decide how far to go by risk

You do not apply everything in Parts 1 and 2 equally to every system. Look at impact × likelihood and set the depth of countermeasures. The same app, given a bigger role, is held to higher standards of control.

1. Auxiliary appe.g. just viewing sales targets on a map — an outage is an inconvenience
2. Department systemrecords and assignments shared within a department — an outage stalls the department's work
3. Customer management (CRM)holds customer data and deal history — bad writes or leaks directly affect customers and trust
4. Core company systemconnected to orders, invoicing and contracts — an outage stops the whole company

Maturity of the setup — beyond the in-house-or-outsource binary

"We can build it" is the first step. Thinking in terms of which step you are on — and which step this system needs — takes you out of the binary choice between in-house and outsourced.

1. Can builda working system exists and is used
2. Can change safelytests, separated environments, reviewed and approved changes
3. Can recover from failurebackups, restore testing, monitoring and incident handling
4. Anyone can take overdocumentation, company control, runs without the original builder
5. Audit & continuous improvementkeeps running on the rules-evidence-improvement cycle

How AI is changing the relationship with development vendors

So far, this has been about the "surroundings" that make software usable for business. Part 3 is about how you commission and verify external work. AI is also changing how you ask, choose and work with development companies.

• Prototype with AI before asking for quotes
• Check proposals, quotes and contracts with AI
• Review deliverables with a separate AI
• Know the cost of the new visibility

Build an AI prototype first — then ask for quotes

In the traditional flow — a written requirements document → quote and order → months of development — it was not unusual to see working software for the first time near completion. That is where misalignment, rework and extra cost were born.

Now there is another option: build a working prototype with AI in days to weeks (your own team can do it), and use that prototype as the shared basis for quotes. The common language becomes working software, not interpretations of words.

Requirements misalignment shrinks

• The people on the ground touch the prototype and surface missing — and unnecessary — features early

Quotes become comparable

• Quotes from several vendors who saw the same prototype expose their differences in breakdown and thinking

The "surroundings" become the comparison point

• With features visible in the prototype, each vendor's account of authentication, operations and warranty — the surroundings — becomes the crux of comparing quotes

* The contrast here is between a document-centered process and one example of prototyping with AI first; traditional processes may also include prototypes and staged checks.

Reviewing vendors and partners with AI

Checking proposals and quotes

• Have AI surface missing work items, double counting and vague assumptions
• Cross-check several vendors' quotes into a form where you can ask about the differences

Checking contracts

• AI review of risk clauses: where responsibility divides, acceptance conditions, subcontracting, return of data on termination
• Dedicated services supervised by lawyers exist. Final checks on important contracts go to professionals

Checking deliverables

• Have delivered code and design documents reviewed by a different AI system from the one that built them
• Quality concerns get surfaced and turned into concrete questions. We do this ourselves — deliverables are reviewed by a separate AI before we hand them over

A caution — AI reviews also contain errors and omissions. Final judgment stays with people, and what may be entered into AI runs under the AI-governance rules of Part 2.

The other side — the cost of the new visibility

This change is not all upside. A client armed with tools to see, paired with a vendor that doesn't expect it — or the reverse — produces new kinds of friction.

Answering findings costs many times more than sending them

• AI review reaches into places that used to be invisible. If every minor finding must be addressed, vendors will price that effort into their quotes
• A real case: for curl, foundational software used worldwide, AI-generated reports surged; in 2025 genuine vulnerabilities fell to roughly 5% of all submissions. Verifying one report takes several people 30 minutes to 3 hours — and in January 2026 the bug bounty was ended

Sending a finding takes a moment; receiving and verifying it stays human work — that is where the imbalance appears.

Refining 90% to 99% costs far more than 9%

• An old rule of thumb — "the first 90% of the code takes 90% of the time; the remaining 10% takes the other 90%" (the 90:90 rule). Visible progress and remaining effort do not match
• The AI era has a similar observation: AI gets you to 70% fast, and the remaining 30% (edge cases, safety, production quality) is where you bog down (the "70% problem")
• The more alive a prototype looks, the easier the illusion of "almost done". Refining 90 to 99 is not a 9% top-up — it can cost as much as everything before it

Mismatched assumptions hurt both sides

• A client fluent in AI × a vendor that doesn't expect it — the volume and depth of findings outruns the vendor's budgeted effort, and requirements go unmet
• A vendor pricing in AI-response effort × a client unaware of it — friction with "AI should make it cheaper"
• Either combination erodes schedules, budgets and trust

We apply this thinking to ourselves

Nothing in this article is a demand on the reader. It is a shared yardstick — the same principles we apply to our own AI-assisted, small-team development.

How we use AI (disclosure)

• Implementation and documents are accelerated with AI; deliverables are reviewed by a different AI system from the one that built them
• People verify the critical parts, and changes are kept in version history
• Client information and code go only into AI services whose contracts and settings exclude training on the input
• Changes of AI or model, and service termination, are handled after assessing the impact
• Source code, contracts and accounts are managed by the company

Advisory and contracting — where responsibility divides

• Advice as a technical advisor assumes that judgment and execution remain with the client
• For work accepted as contract development, the contractor is responsible for the deliverables
• Which hat is being worn is made explicit each time

Decide who has the final say

• As AI, advisors, vendors and internal staff multiply, the seat of final judgment blurs easily
• For each domain, decide separately who executes and who finally judges and bears responsibility

References — on the changing shape of commissioning, and the effort-quality wall

Public articles, an academic paper and rules of thumb we had confirmed as of August 24, 2026. The views are the authors' own and may differ from ours in places. Articles marked (in Japanese) are Japanese-language sources.

Not "who builds it" — but how the necessary roles, responsibility, verification and continuity are put in place

Building in-house with AI is entirely realistic. What AI reduces is mainly working effort and headcount. Roles, responsibility, mutual verification, continuity and accountability do not disappear with it.

Judge in-house

• Business rules, features, improvements and daily operations stay in your own hands
• With AI-enabled role-combining, a small team can carry many roles

Put third-party verification at the key points

• High-impact changes, security and key design points get eyes other than the author's
• The verifier can be a different person in-house or external (a separate AI assists verification)

Use expert support only when expertise is needed

• Surfacing issues, design review, an audit perspective — only the moments that need it
• Where the support comes from doesn't matter: external specialists, auditors, a technical advisor