AI editing project
An editing environment such as Lovable, with the access and guidance your team needs. We confirm the chosen service’s capabilities for your project.
buildsfor · A development service by Nihonbashi AI Lab
Business software your team can keep improving.
Show us the documents, spreadsheets, and work you want to improve. NAL uses AI to build software around your workflow and helps your team learn to make the agreed everyday changes.
Start with a consultation. Scope, delivery, and costs are agreed before development.
Choose how you will keep working on it.
Delivery can combine an AI editing project, a GitHub repository, and a ZIP snapshot. We recommend a combination based on who will maintain the software and where it will run.
GitHub repository
Source code, change history, and instructions for building and updating the app. Useful for your developers or a future development partner.
ZIP snapshot
Files and guidance for an agreed delivery version. A snapshot is separate from the full change history and the environment needed to run the app.
Hosting, external services, and ongoing maintenance are agreed separately. Docker, internal servers, and other delivery environments require project-specific checks.
Know what your team can change.
We agree a practical scope for self-service changes and include hands-on handover. Optional support covers the work that needs specialist help.
Everyday changes your team practices
For example, update screen text or adjust supported export columns and settings. The scope depends on your app, with sample data and checks to confirm the change.
Changes with specialist support
Login and permissions, database changes, or complex integrations may need expert review and implementation. We make those boundaries clear at handover.
Agreed before full development begins
- Who edits it and which tools they use
- Projects, source files, and instructions to deliver
- Where it runs and what services it needs
- Account ownership and access responsibilities
- Development, running, and support costs
- Functional checks and the handover exercise
You do not need all the answers to start. NAL helps define them during scoping.
Try the workflow
Check order data. Export it your way.
Use fictional orders to correct missing data, check totals, and change the CSV layout yourself.
Operation example using fixed fictional data. No documents are uploaded or read by OCR. Edits stay in this tab and disappear when you leave or reload.
Fictional order reference
| Order number | Order date | Customer | Product | Quantity | Unit price | Amount |
|---|---|---|---|---|---|---|
| DEMO-001 | 2026-09-01 | Sample Office A | Notebook | 2 | 1000 | 2000 |
| DEMO-002 | 2026-09-02 | Sample Office B | Paper set | 3 | 1200 | 3600 |
Check and correct
Amounts are whole Japanese yen (JPY). Changing a value clears this order’s confirmation.
Change CSV column names and order
Try changing a header or moving a column. The order data stays the same.
CSV preview
| Order number | Order date | Customer | Product | Quantity | Unit price | Amount |
|---|---|---|---|---|---|---|
| DEMO-001 | 2026-09-01 | Sample Office A | Notebook | 2 | 1000 | 2000 |
| DEMO-002 | 2026-09-02 | Sample Office B | Paper set | 3 | 1200 | 3600 |
Spreadsheet formula prefixes are exported as literal text.
Correct the highlighted fields and check both orders before downloading.
Read the delivery process reference
AI agents, forward deployed.
Turn one customer problem into a stronger standard Build.
buildsfor applies AI agents to the Forward Deployment loop: understand the work, test product fit, implement an accepted standard-product change, validate it, support deployment, and return reusable learning to the common product line.
- Current state
- Public operating model · AI execution not connected
- Workflow revision
- buildsfor-forward-deployment-workflow-v1
One cumulative loop
From a bounded need to a reusable successor Build
Each stage produces an inspectable record. A customer request does not jump directly to coding, availability, or a maintained private fork.
- 01
Bound the problem
Organize the desired outcome, current workflow, users, information class, integration boundary, deployment constraint, and success measure.
Problem Brief
- 02
Decide fit or no-fit
Compare the brief with an exact standard-product truth revision. Unknown boundaries remain review items instead of becoming positive claims.
Fit decision + reason codes
- 03
Fix the deployment plan
Name the exact product revision, allowed configuration or common change, data boundary, validation method, responsibilities, and stopping conditions.
Versioned deployment plan
- 04
Implement with AI agents
AI agents prepare the accepted configuration, common mainline improvement, or separately productized extension within the fixed plan.
Traceable change set
- 05
Validate the exact change
Run bounded tests and produce Evidence that states what was checked, what was observed, and what remains outside the claim.
Checks + bounded Evidence
- 06
Deploy through Owner gates
Nihonbashi AI Lab retains authority for customer access, confidential data, production changes, exceptions, and final acceptance.
Owner decisions + acceptance
- 07
Return learning to the product
Reusable improvements become a common successor BuildVersion or a separately versioned extension, available for later fit decisions.
Common product revision
Execution and accountability
AI agents do the delivery work. NAL holds the authority.
The target is not a permanent manual development service and not an unsupervised customer-facing coding agent. Automation and accountable decisions have different roles.
AI agents
Prepare and execute the repeatable technical work inside accepted boundaries.
- Structure the Problem Brief and compare it with exact product truth
- Prepare the deployment plan, configuration, common change, or extension
- Implement, test, document, and assemble bounded Evidence
- Prepare deployment steps and a reusable successor-product change
Keijiro / Nihonbashi AI Lab
Remain accountable for the customer, product, data, and production decisions.
- Set product priority, price, contract, rights, and customer commitments
- Authorize confidential-data handling, credentials, and customer access
- Approve production actions, exceptions, and incident responses
- Agree the acceptance boundary and final disposition of reusable changes
Standard-product discipline
Every request ends in one of four product outcomes.
buildsfor does not preserve a separate maintained fork for each customer. A need must fit one controlled product disposition.
Configuration or setup
Use the existing standard product without changing its maintained product lineage.
Common mainline improvement
Improve the standard product for this customer and future customers through one shared product line.
Productized connector or extension
Create a separately versioned reusable component only when it can become a maintained product asset.
Refuse the request
Do not force a need into the product when it cannot meet the standard, authority, or reuse boundary.
Fail-closed boundaries
What this workflow does not claim
No maintained customer-specific fork
Customer-specific code does not silently become a second private product line.
No automatic production authority
AI output alone cannot create a contract, release, entitlement, deployment, acceptance, or production change.
No customer-data intake here
This page does not collect a project description, document, contact detail, credential, or confidential information.
No connected AI delivery runtime yet
The public workflow is real and versioned, but Gemini, Codex, and other execution providers are not connected through this page.