Service first and SaaS later is useful advice, not a law.

Jon Yongfook argued in a November 4, 2026 post^{[1]November 4, 2026 post} that new founders should begin with AI-enhanced productized services and build a software product after learning what customers pay for. It is an excellent antidote to spending months on a beautiful product with no buyers.

We agree with the value of that learning. But when a company has an existing platform, software may sometimes be the thing that makes the service possible in the first place.

A paid website migration, procurement analysis or media workflow supplies real constraints. The client tells you which parts matter and which failures are unacceptable. Revenue finances the repeated operations that might later become software.

Service work also prevents a team from mistaking technical curiosity for demand. A useful question is not how quickly the product can be generated, but whether anyone has a problem they will pay to solve.

Some capabilities have a portfolio-wide payoff: an identity layer, a local inference engine, shared catalogue records or a reliable account-application interface. They may be uneconomic as a dedicated project for one customer while valuable across dozens of future projects.

One way to reason about an investment is expected value = direct margin + reuse value + option value − operating cost. This is a planning framework, not a forecast. Early service contracts may dominate the first term, while infrastructure investments affect the second and third.

Aurekai mixes both. We want to learn through customer work, use existing business knowledge and build durable infrastructure where it can benefit many businesses.

The useful part of Yongfook's advice is to stay close to real customers. The counterpoint is that the next opportunity need not start with an empty repository or a new one-person consultancy. A shared platform changes the sequence.