I went to KubeCon + CloudNativeCon Japan 2026 in Yokohama. The main conference ran two days, with a co-hosted event the day before; I made the co-hosted day and day one of the main conference, and missed day two for a personal commitment. Going in, my view was that Kubernetes is a tool for organizations that need flexibility to absorb large-scale traffic — and therefore has nothing to do with a fledgling app developer like NASEBANAL. What I found instead were insights that connect directly to my own business. This post covers the four biggest lessons — Kubernetes as a test harness, the architecture debate around agents and what to expect of them, NVIDIA's take on using agents for root-cause investigation during incidents, and the FinOps of running agents themselves as argued by Cast AI and Kimchi — each tied back to what it means for NASEBANAL.
At the end of my last post I said the next step would be mobile — and I'm now building it. NASEBANAL Growth Mobile bundles the Target, Recorder, and Stopwatch apps into a single client, built by taking the existing Web UI as the baseline, designing the screens with Figma MCP from inside Claude Code, fine-tuning the Figma stills by hand, and then auto-generating the app from those screens plus the OpenAPI Spec. Along the way, dark mode — which came almost for free on mobile — gave me the nudge to bring Light / Dark / System to the Web apps too; because a shared component package (bundling the UI foundation and the color palette as design tokens) and the API spec are factored out as shared packages, that stayed a light change. To close, I lay out why this whole flow is exactly the approach I've been shaping for in-house-development support.
In my previous post I promised a closer look 'next time' at our work on Contract-Driven Development (CDD), so here it is, laid out afresh. Why CDD helps reconcile spec clarity with quality assurance, why I chose Specmatic over Pact — the flagship of CDD — (the limits of Consumer-Driven contracts, and how well an OpenAPI-spec-as-contract approach fits), and the pipeline I built by running NASEBANAL's Spec, backend, and frontend through a full loop, plus what I took away from it. This is where my hypothesis stands — putting the OpenAPI spec at the center as a shared guardrail for a future where in-house, outsourced, and AI-agent development coexist.
Alongside the launch of our developer-facing site [NASEBANAL API Specs](https://api-specs.nasebanal.com/en), I'd like to share the concern behind it and the work it has prompted. AI coding accelerates feature implementation, but our understanding of that implementation struggles to keep up, making it hard to see what state the code is in after each PR and Merge. This post lays out two efforts aimed at that challenge of 'making the state of development visible' — laying the groundwork for Contract-Driven Development (CDD), starting with splitting the API reference into its own site, and making development visible through DORA / Code metrics and token consumption — and reflects on the role of the OpenAPI spec in a future where in-house, outsourced, and agent development coexist.
We are launching the beta of NASEBANAL Target, a new app that decomposes goals as a tree and visualizes progress with real data from NASEBANAL Recorder. Target accommodates both Mandala-Chart-style top-down decomposition and mind-map-style organic branching, and surfaces the time-series chart of each node's linked Recorder tag right where the goal lives. Sharing a tree shares not just the structure, but the data behind it — so you exchange the *reason* you were tracking those numbers, not only the numbers.
Why we built a versatile data tracking tool. A Tokenization-inspired approach to security, predefined category tags, and OGP graph images for SNS sharing.
NASEBANAL Recorder is now in beta. Tag-based flexible data management, REST API integration, and one-URL public sharing pages — a general-purpose metrics recorder built for people, not just systems.