How Netsujo SIGNAL Grew Out of Our Own Website Improvements
Tomohiro Iida ·
Netsujo did not begin by drawing a product roadmap for external customers. It began with two sites we already operated: netsujo.jp and miyakodeit.com. We wanted visitors to find the right information, understand it and take an appropriate next step. We explored each obstacle with AI coding agents and human review, then accumulated repeatable checks, implementation specifications and verification methods.
Key takeaways
- The two sites served different goals: qualified business enquiries on the company website; community participation, events and collaboration on the local community site.
- We chose actions and reader decisions before rankings, impressions or traffic volumes. These metrics are evidence along the way, not revenue or participation by themselves.
- The repeatable workflow later became Netsujo SIGNAL: observe, trace causes, specify changes, implement through an authorized party and verify what actually changed.
- The October 2026 product definition is a continuously improving website sales foundation. It helps people discover, understand, compare and decide whether to enquire or order.
- A specification being complete, code being released and a business outcome improving are three separate facts.
The first problem was on two sites, not a product roadmap
The Netsujo company website needed to help potential customers judge our services and contact us about relevant work. MiyakodeIT had a different job: helping developers find events, join activities and explore collaborations. Applying a single universal traffic or conversion target would have hidden those different intentions.
We worked backwards from each intended decision. What does this visitor need to know? What evidence helps them trust it? What technical issue prevents that information from being found or understood? A search result may bring an impression without a click. A page view may occur without a meaningful request. Each metric answers only a part of the question.
AI shortened the loop; it did not decide what success meant
AI agents helped investigate content, metadata, rendering, internal links, structured data, measurement and code changes. They could propose or implement changes quickly. But a human still needed to choose the reader outcome, check the evidence, authorize a production change and interpret results. Automation made the cycle shorter only when every step had an explicit question and acceptance criteria.
Repeated work gradually developed into a shared method: observation, opportunity trace, change specification, implementation and verification. An issue is more useful to an implementer when it includes the target URL, confirmed evidence, what remains a hypothesis, requested change, exclusions and how to test completion.
We describe eight diagnostic areas: presence, discovery, retrieval, trust, understanding, action, measurement and improvement. They are a way to locate a cause and frame a proposed change; an eight-part score alone cannot establish why a buyer chose not to contact us or prove that a fix worked.
An internal tool and a customer service are different systems
On our own sites, we could fill gaps in documentation from personal knowledge. A client cannot reasonably be expected to know those internal assumptions. Productising the work therefore required clear boundaries around site access, the meaning of a diagnosis, responsibility for implementation, customer approvals and how to handle incomplete measurements.
The product also depends on widely shared foundations: open source software, cloud infrastructure, AI models and the engineers who built those tools. Calling it the output of one person would ignore that reality. The useful contribution was integrating those capabilities around an explicit customer problem and a reviewable operating method.
What SIGNAL is intended to do as of October 2026
The service aims to make a company website a sales foundation on which a customer can independently discover, understand and compare an offer, then make an informed enquiry, purchase or commissioning decision. The purpose is to reduce repeated explanations and leave humans more time for conversations where individual requirements and trust really matter. It does not imply a fully automated sales process.
The distinctive work is to follow obstacles to the level of code and settings where access is authorized, and to produce a change specification that the customer’s AI, internal developer or existing web agency can use. Public-information scans cannot inspect private source code. Each implementation and production release has its own contract, access boundary and approving owner.
SIGNAL offers a public-information diagnostic as an entry point. Diagnosis, ongoing assistance and direct implementation have different plan boundaries; refer to the current service terms for the scope and price of each. Even a released improvement does not prove that enquiries or sales rose. Later measurement must distinguish observed user behaviour, measurement quality, external effects and concurrent changes.
The next proof has to be about buyer decisions
A working diagnostic dashboard, an opportunity trace and a change specification are valuable intermediate outputs. They should ultimately help a real customer judge an offer and make an appropriate next move. We need evidence for implementation acceptance first, then evidence about qualified enquiries, purchases or reduced repetitive work. Not every signal is observable yet, and that uncertainty belongs in the report.
How our GA4 and Search Console analysis is structured
How to share implementation responsibility with an existing agency
Use the public scan to identify an issue worth checking before requesting code changes.