TL;DR

• A renewal notice arrived for our attendance SaaS: 300 people, ¥200/person/month, ¥720,000 annually.
• The number was acceptable. The problem was fit, not cost — two requirements (actual travel-cost reconciliation; network-based in-office determination) fell outside the standard SaaS spec.
• I rebuilt the system in Google Apps Script (GAS) in a few hours, with AI as the coding resource. I call this human role an "AI Director."
• Beyond cost: agility (same-day requirement-to-system), data ownership (lock-in avoidance), and a new development flow — build a working sample, then hand it off to a SIer for production lift.
• Bonus thoughts on where programmer knowledge stays valuable (specialist domains, post-AI quality review). A gold-rush analogy.

---

Chapter 1: Requirements — Why the SaaS Stopped Fitting

A generic SaaS is designed around business processes shared by many companies. That's a sound design philosophy. But for an organization carrying company-specific logic, the company's business doesn't fit what the SaaS provides.

Two requirements fell outside the standard spec in our case:

• Travel-expense reconciliation against actuals: Specific rules on commuter-pass routes and per-day route determination. The SaaS's default aggregation couldn't handle it.
• Attendance determination by network: We wanted to decide "remote vs. in-office" by whether the punch came through the corporate network. Location-based determination wasn't precise enough.

Two ways to do this with a generic SaaS: pay for a custom development option, or use a CSV export + post-processing workaround. The former inflates cost. The latter produces a kind of inverse vendor lock-in — your operations get locked into manual workflows that only you understand.

The decision was simple. Hire AI as an external coding resource and rebuild the system in GAS to fit our requirements.

From implementation start to operational verification, it took a few hours. The AI wrote the code. Humans handled requirements and specification adjustment. In this article, I'll call this human role an "AI Director." I use the term in the sense of an individual practitioner directing AI as a coding resource — not the executive "Director of AI" role established in larger organizations. This role overlaps significantly with what's framed as a "Citizen Developer using AI" in adjacent discussions; I emphasize the directing relationship with the AI rather than the citizen vs. professional dichotomy.

Chapter 2: Breaking Through Physical Constraints (Ver.1 to Ver.4)

During development, the location-acquisition approach switched four times. Each switch was a discovered constraint and a design decision to work around it.

Ver.1: HTML5 Geolocation

GPS on smartphones gives reasonable precision. But punches mostly come from PCs, where Geolocation falls back to Wi-Fi triangulation or IP-based estimation. The errors landed in the kilometer range.

Not enough precision for in-office determination. Rejected.

Ver.2: IP-Based Estimation

I mimicked the fallback approach used by many SaaS products. Call an external API to estimate geographic location from client IP, then convert to an address string.

The errors here were also large. Carrier routing causes "home" to surface as "near Tokyo Station" in many cases. Not viable.

Ver.3: Google Maps Reverse Geocoding (Built into GAS)

GAS includes a Maps service. Maps.newGeocoder().reverseGeocode(lat, lng) performs reverse geocoding at no cost. This removed the need for an external API key for lat/lng-to-address conversion.

Precision issues remained, but on cost, this had a clear edge over the SaaS.

Ver.4: Master Matching as Proof of Attendance

The final solution wasn't to improve location precision. It was to change the determination axis itself.

When a punch comes through the corporate network, the global IP is the company router's fixed IP. Match this IP against a master of corporate-site addresses. If it matches, "in-office" is confirmed. Location precision becomes irrelevant to the question.

This reduces to deterministic IP-master lookup, so error doesn't structurally arise. For the purpose of attendance determination alone, IP matching is more accurate to the requirement than Geolocation.

Chapter 3: What the System Does

The final form has:

• One-tap punch: Browser, one button, clock-in/out recorded.
• Dynamic location recording: IP master confirms "in-office"; otherwise Reverse Geocoding records the address string.
• Automated monthly aggregation: Per-person attendance-day counts, computed from corporate-site master matching.
• Data ownership: Punch data accumulates in our own Google Spreadsheet. No export operation. Even after cancelling the SaaS, the data remains.

The last point matters for vendor lock-in avoidance. With a SaaS, cancellation typically means losing access to historical data, or being constrained to CSV dumps. Internal development places the data structure itself under our control.

Chapter 4: AI's Asymmetric Leverage

Most AI-coding-support articles frame productivity as "the programmer becomes N× faster."

That's a vertical-axis story. Within the same role, throughput rises. Faster typing, faster code review, faster refactoring.

What happened here was a different direction of leverage.

When a person with domain knowledge uses AI, a business system that previously went through "business side → engineer outsourcing → implementation → review" can be built directly, skipping the intermediate steps.

The second form of leverage is asymmetric in market terms. Programmer productivity gains accelerate competition among programmers. The domain expert's AI use crosses the boundary of professional categories entirely.

Acceleration along the vertical axis, versus crossing the boundary. These are leverages of different types. The AI Director embodies the latter.

Chapter 5: Using the Sample as a Deliverable — The Specialist Handoff Option

Pack all the attendance requirements into a sample system that runs for at least one person. From there, you could spend time building login management, change-request approval flow, database management, and other production-grade elements yourself.

But at this point, handing the work off to a SIer (system integrator) is a viable option.

You have everything the business wants captured, a working sample, and the GAS code. This amounts to having completed requirements definition, part of the basic design, functional design, and detailed design.

If you simply ask the SIer to turn this into a system that all employees can use, the cost should be significantly lower than traditional outsourcing.

Further, if a proper SIer delivers a production-quality system along with specifications and system-design documents as deliverables, the only remaining changes are scale adjustments (employee-count changes) and rare-case incorporation. By feeding the specifications and system design back into AI as the current environment, you may be able to handle those changes yourself.

Build the logic yourself, let specialists raise it to production quality, and own the deliverables.

The current AI isn't a magical do-anything tool — it's an extension of your own thinking. Recognize that your own limit is AI's limit. When a problem doesn't yield in 30 minutes, list it as an open issue. Then have others solve it. Or have them review and suggest a path forward.

The usual system development, with AI in the middle reducing the issue count. This is what I see future system development trending toward.

Chapter 6: Conclusion

Saving ¥720,000 annually isn't the primary outcome here.

The primary outcome is the ability to rewrite the system the moment business requirements shift. Instead of waiting for the SaaS vendor to add features, the system follows on the day you write the requirements. This agility isn't fully captured by cost calculations.

In the AI coding era, the market value of "being able to write code" is in relative decline. What rises is the ability to define what should be built, instruct the AI correctly, and verify the output.

It's less a new profession than the arrival of an era in which people who already hold business knowledge can — by having AI as an implementation layer — restructure their own business domain as a system.

The ability to operate as an AI Director — defining requirements, having AI build, and integrating into operations — fits as one of the basic survival strategies in today's business environment.

Bonus: Where Programmer Knowledge Stays Valuable

This article leans toward the AI Director perspective. Let me also organize patterns where programmer knowledge stays valuable.

Specialization in Areas Where AI Falls Short

Real-time control, embedded systems, security, formal verification, mission-critical domains. Running AI-written code without verification isn't socially acceptable in these areas. Fields requiring depth of specialist knowledge and robustness remain programmer territory.

This isn't a domain an AI Director can cross into. It's a direction in which programmers become purely stronger.

Monetizing Specialist Knowledge

Separately, I had AI draft a contract and asked a lawyer for the final review. With 2-3 comments, it was done for ¥5,000.

This is one illustration of how specialists sit in the AI era. Even when AI does the drafting, specialist review retains its value — legal responsibility, hallucination mitigation, expert judgment.

The same structure applies to programmers. The sample that an AI Director builds needs SIer/programmer review at the stage of lifting it to production quality. The role shifts from "time spent writing code from scratch" to "time spent evaluating code and raising it to production quality."

In an era where production has become easy, you don't have to stay on the production side. You can move to the side that raises quality, or builds the systems. A gold-rush analogy fits: rather than swinging a pickaxe to dig for gold, you can be the one selling pickaxes, or refining the gold.

AI now covers the areas that have historically consumed programmers' time. The opened-up time can be redirected toward deepening knowledge of methodology and algorithms. Let AI handle production. Move to the side that critiques as a specialist. This may be the model pattern for programmers and, by extension, all specialists.