The Weekend Build

"If you wish to make an apple pie from scratch, you must first invent the universe." — Carl Sagan

They say boredom is a hinge in the door of ingenuity, and I tend to agree. Some of the most useful things I've ever done were born in a moment of inescapable boredom (usually accompanied by ornery cousin, curiosity). Being bored is how I wound up vibe-coding internal tools on weekends. I can design and deploy working software by describing it to a model and watching it appear, and pieces of how this very note reaches you were made that way, by me, not bought from anyone.

The gatekeeper of computer-based lego pieces used to be deep coding knowledge. While that skillset still matters, thanks to model-assisted tools anyone with an idea and a robust enough vocabulary can take an idea and ship it into workflow automation in a matter of hours — minutes, if you're not perfection-obsessed. As I watch AI companies step forward with increasingly polished products, the old question reappears in a new outfit: make or buy? We've lived in an instant-gratification economy for a long time, but AI nudges us toward something different: individual autonomy over tooling. Is this the moment to leave it to the professionals, or is there real merit in building your own castle?

The loud vendor-side pricing argument this summer is about how to buy. Seat license, consumption meter, tiered usage, etc. In my corner of the office, we're busy trying to understand where the efficiency is showing up, how to measure it, and how to fold that back into future work estimates. How the buy-side of the firm moves forward will shape the datasets we have tomorrow. In the middle of those discussions lurks a larger question: what if we didn't buy at all?

"Make versus buy" used to largely settle itself in legal tech, because "make" meant a capital project that rarely beat the economics of vendor-ready products. The old assumption that you won't find a robust, full-stack engineering team inside BigLaw is, however, eroding. At the top of the market, building is suddenly real and serious: Kirkland is reported to be putting around half a billion dollars into co-building an AI platform with Palantir, and other firms have stood up data-science teams or struck model-provider partnerships to build what no off-the-shelf tool delivers. There is no reason to think this interest will stop at IT's door and not cross into legal ops. A pricing analyst with no engineering background can describe a matter-margin tool and have a working version by Sunday night. The word "build" now stretches from a half-billion-dollar platform to a free weekend, and that distance is the whole point of this piece.

The case for building seems strong, and it should not be strawmanned. Architecting your own system gives you exact fit with no vendor roadmap and no workflow bent to another firm's idea of how pricing, staffing, or BD copy works. You can run experiments for the price of an afternoon, and sometimes the fastest way to understand a problem is to build the ugly version and watch where it breaks. There's a data argument too — keep your rate history and your write-off scars in-house instead of feeding them to a platform — though that one is shakier than it sounds, and it deserves a harder look.

So, what happens when the weekend high of building a functional model meets the Monday use case?

Building isn't free. It's just billed where we're often not looking.

Start with what the skill alone costs. TVPi, where many of us earned our pricing accreditation, runs an AI-agent workshop for pricing and legal-ops professionals at around $4,500 a seat. There is a market rate to learn "make," especially from community-recognized experts. That isn't a knock on the workshop, which may be genuinely useful, particularly to people who find the prospect of opening Claude Code without a line of native coding language intimidating. The price tag is a tell.

If you're paying a seat fee, usage credits on your own account at home, or for a certification in AI proficiency, that's only the front of a cost curve whose back half nobody prints on the brochure — the maintenance, the debugging, the slow pile-up of things only you understand.

The weekend build is free the way a puppy is free. The acquisition cost is not the end of the story.

So where does buying win? In places a weekend build can't follow on its own. The first, and arguably most measurable, is the gap between "anyone can build this" and "anyone can build this safely and well." Vibe-coding made the first one true. It did nothing for the second.

Here's what it feels like in practice. The person closest to the workflow is often the best person to sketch the tool — they know the inputs and edge cases, the exact shape of the answer they need. Inside the four corners of a small team, that can scale fine. The trouble starts the moment it must become weight-bearing rather than accessory to practice, and it shows up as two problems most weekend builders never see coming.

The first is integration. A pricing tool nobody else can feed is a toy. It can absolutely add efficiency, but only in a small radius. A power tool will plug into the systems the firm runs on: the billing software, the CRM, the data warehouse. That connection is the heavy lift, and it's a different sport than describing an app to a model on a Sunday. It means authenticated access to the system of record for every dollar the firm bills, pulled correctly and securely, without breaking the thing you tapped. Most novice builders can't clear that bar (and the ones who can are often the exact people IT would never hand the keys to in the first place). The toy is easy, and useful as an accessory. The tool is an enterprise-integration project.

Say you clear it anyway. Best case: you build something genuinely useful, and it integrates. Now it needs to stay alive. Software isn't a thing you finish, it's something you keep and maintain. Dependencies drift, security holes open, and the billing system you plugged into ships its own update that silently breaks your connection at 2am. Holding a tool together through all of that is a full-stack engineer's job, and unless one happens to sit near the pricing desk, the rot goes unwatched.

This is where the build bites sneakily, because code doesn't fail the way the rest of software trained people to expect. There's no red box, usually no 404 error to tell anyone to stop. The broken version still runs, still looks functional, still returns a clean and confident number — and the only way to catch that the number is wrong is to already know where to look. Knowing where to look is exactly what got skipped when the model wrote the part nobody understood.

The platforms that could have been bought instead carry all this maintenance ownership, because someone is paid full-time to read the blueprint, monitor the logs, and keep the thing standing.

Governance is the last wall, and for a pricing /legal ops tool it has less to do with hackers than with accountability.

If a self-built tool computes or presents a fee in a way that doesn't square with how lawyers are permitted to bill, the error stops being merely financial; it can put a number in front of a partner or client that the conduct rules don't support. The same goes for the trust layer: when an AI-derived figure lands in front of a stakeholder, be it the savings line in an RFP, the margin under a flat fee, its integrity is an asset, and a black box no one can fully explain dismantles it.

This survives even a closed-loop, on-prem, nothing-leaves-the-building setup. Governance was never only about whether the data leaked. It's about who is allowed to change the logic without a second set of eyes on it, and who gets called at 11pm when the thing falls over the night before pricing committee. On a weekend build, nobody reviews the change, and the one being called is usually the person who made it. That may be workable in a sandbox; however, it is a risk signal in a risk-averse environment.

The generic numbers back the instinct, for what it's worth: security audits keep finding flaws in most of the AI-generated code, and most enterprises admit they run with little or no formal AI-governance framework. Those studies are about public-facing software, and a fair critic will note that an internal pricing tool which never touches the open web carries less of that exposure. Fair. Exposure still exists for pricing teams because the data is sensitive and the bill it shapes belongs to a client.

This brings us back to the data argument, because it deserves a harder look than the build crowd tends to give it. "Keep your proprietary data in-house" sounds airtight until you watch how these tools run.

In most weekend-build scenarios, a pricing or LPM tool is not truly local. It calls a hosted model over an API, which means some representation of rate data — raw, summarized, or embedded — crosses into someone else's infrastructure whenever the tool does anything useful. That does not mean the data is automatically ungoverned, but it does mean the sovereignty story is often less complete than the rhetoric suggests.

Unless a firm is genuinely running a local or privately hosted model where it controls the runtime, networking, and logging, that setup is an infrastructure program, not a side project. It demands MLOps, security engineering, and ongoing support that a "build it on Sunday" story lacks.

For most pricing and LPM use cases, the risk that bites first is not espionage; it's error. A tool that confidently misprices a portfolio of matters can quietly destroy margin or client trust long before any theoretical data exfiltration event. The real risk is not that the numbers will walk out the door. It's that the tool carrying them gets them wrong and no one notices them in time.

This is where the professional builds and the weekend builds stop being the same activity. Kirkland co-developing a multi-year AI platform with Palantir is proof that BigLaw can do the heavy lift when it wants to — a half-billion-dollar bet on owning core workflows and institutional knowledge, not just renting another dashboard. Other firms are standing up data-science teams or striking deep model-provider partnerships for the same reason: they see AI as infrastructure, not a toy.

But that level of build doesn't happen on a Sunday. It comes with product managers, engineers, governance committees, and service-level promises to partners and clients. Meanwhile, pricing doesn't wait. Matters open on Monday whether a firm's AI program is in year zero or year five, and clients are already asking for something more interesting than standard hours times standard rate. Surveys keep finding that a large majority of corporate clients now use alternative fees and more than half plan to expand that use, which means the expectation of creative, data-driven pricing is no longer theoretical.

In that world, tools you can spin up outside the formal AI program aren't a sideshow; they're often the first way to meet demand. A well-chosen, external AI-enabled pricing product can put useful capabilities on the desk this quarter, while the Palantir-scale builds are still in flight. Those buys can give pricing teams an edge in responding to RFPs, modeling scenarios, and testing new fee structures long before an internal platform is mature.

The dividing line was never simply build versus buy. It's governed versus ungoverned, and timely versus theoretical. A weekend tool is the ungoverned cousin of what a serious firm pays real money to do properly; the price gap is precisely the cost of the wrapper and the urgency of delivery.

As someone who will keep building, this is where I land:

Build the prototype — and build it responsibly. If a tool is going to live as more than an accessory, commit to learning the backend, not just the front end. Understand how it authenticates, what data it moves, where it logs, and what happens when something upstream changes. If that ownership is out of reach, treat the build as what it is: a sketch, not a system.

There is real value in that sketch. Play. Discover what your own workflow is missing by building the ugly version and watching where it hurts. Use prototypes to sharpen your requirements, your sense of risk, and your identification of workflow bottlenecks. Then be honest about the boundary: know where the risk lives, and when it's worth bringing in someone to protect the firm — whether that means platform engineering, security, or a vendor willing to sign up to real obligations.

"Make" looks cheaper only because its real costs are deferred and smaller at first, until the quarter they all come due at once. "Buy" looks dearer only because its price is honest enough to show up on a statement. A pricing professional, of all people, should not be the one fooled by a cost that is merely hidden.

Build with curiosity but deploy with humility. Keep the weekend energy. Just do not confuse a prototype with a product, or a hidden cost with a cheap one.