Semantic Rebase

Over summer, I’ve been experimenting with more autonomous coding agents. In our work at Icehouse Ventures, I basically read every line of code that we commit to production and we optimise heavily for security and stability. We do use a lot of AI tooling, but we keep it on a much tighter leash than a lot of the looser modern tech teams working on consumer software. I find that the Kiwi summer holidays are a perfect time for some light side-projects and exploring new trends. One thing that’s come up a lot during the last year and seems to be accelerating is the ability of coding agents to make large scale changes to a large scale code base. By themselves these create a bit of review problem, but when several large scale refactors collide things can become irreconcilable.

Git isn’t powerful enough to keep up with Agent Swarms

Steve Yegge’s recent piece on AI agent swarming raised a concept that’s been rattling around in my head for a while: the “Merge Queue” problem. If you’re running multiple coding agents in parallel Cursor, Claude, Gemini, whoever… you’ve probably already felt this pain. Each agent starts from the same baseline, does meaningful work, the peer-agent code reviews make sense, but when it’s time to merge… chaos. The codebase has shifted so dramatically in the meantime that a normal merge or even a rebase before merging is no longer feasible. As Steve puts it:

“When the fourth agent D finishes its work, a rebase may no longer be feasible. The system may have changed so much that D’s work needs to be completely redesigned and reimplemented on the new system baseline.”

This got me thinking. We’ve been using the word “rebase” to describe a mechanical git operation. But what we actually might need, especially in the age of AI-assisted development, is something more expansive. We could call it a Semantic Rebase.

Level 1: Mechanical Merge (Simple Rebase)

This is what git rebase actually does. Replay commits onto a new base. It works beautifully when your changes are textually compatible with the new baseline—when the files you touched haven’t fundamentally changed.

git checkout feature-branch git rebase master
Assumes: Your changes are additive. The code you modified still exists in roughly the same shape.

Fails when: Someone restructured the module you were working in. Your commits literally can’t apply.

Level 2: Conflict-Resolution Rebase

This is what most developers do when Level 1 fails. You merge, you resolve conflicts, you move on. IDEs are helpful here. You’re still operating at the textual level, but with human judgment applied to conflicts.

Assumes: The shape of the code is still compatible. The architecture hasn’t fundamentally shifted.

Fails when: Your branch assumes a certain directory structure, API pattern, or architectural approach that no longer exists in master. You’re not just resolving conflicts—you’re trying to fit a square peg into a round hole.

Level 3: Intent-Preserving Reverse Merge

Here’s where things get interesting. At this level, you stop trying to mechanically merge code and instead ask: what was this branch trying to accomplish?

You extract the intent of the feature, then reimplement that intent on the new architecture. Personally, I sometimes do this manually by merging master into the feature branch before trying to do a PR. It can be a bit impolite doing this type of “reverse merge” onto a human’s code as you’re effectively taking over their code, whereas an agent doesn’t mind.

This is fundamentally different from Levels 1 and 2 because you’re doing:

code₁ → intent → code₂

Rather than:

code₁ → code₂

The original code becomes reference material rather than source material. You’re not replaying commits—you’re rescuing functionality.

Assumes: The feature concept still makes sense in the new architecture.

Fails when: The architectural changes have made your feature obsolete, or the approach fundamentally incompatible at a conceptual level.

Level 4: Semantic Rebase (Reconciliation based on Meaning)

This is the hardest case, and the one Steve flags directly: “What should we do if Worker A deleted an entire subsystem, and Worker B comes along with a bunch of changes to that (now-deleted) subsystem?”

At Level 4, you need to understand not just what changed, but why. Maybe Agent A deleted that subsystem because it was replaced with something better. Maybe Agent B’s changes should now target the replacement. Or maybe Agent B’s work is simply obsolete and the problem it solved no longer exists.

This requires genuine understanding of both the old and new systems. It’s the level where human judgment (or very good AI judgment with full context) becomes essential. A semantic rebase doesn’t merge the code, it merges the meaning.

Why This Matters Now

For most of software development history, mechanical merges and rebases were sufficient. Teams worked on separate features. Branches lived for days, not weeks. And if they did become a dreaded “Long Lived Feature Branch”, you could periodically merge master into the feature branch to keep the home fires burning. The codebase didn’t shift that dramatically between branch creation and merge.

AI agent swarms change this equation entirely. When you have three, five, or ten agents working in parallel, each capable of making sweeping changes, the probability of deep structural conflicts goes up exponentially. This summer, I’ve been building an open source experiment in advanced source control tooling partly because I needed visibility into this exact problem: what are all my agent worktrees doing, and how badly are they about to collide?

The traditional git model assumes one canonical history that everyone’s rebasing onto. The swarm model creates multiple divergent histories that all need to converge. That’s a fundamentally different problem.

The human-in-the-loop

Yegge predicts the rise of the “superengineer”, someone who can orchestrate 100 coding agents and get meaningful work done with them. I think he’s right, and I think things like rescuing or reconciling divergence among agents (through things like a Semantic Rebase) will be one of the core skills that separates effective agent orchestrators from everyone else.It’s not about being better at resolving git conflicts. It’s about recognising when mechanical rebase is futile and switching to intent-preservation mode.

Something I’ve found helpful for codifying the semantic intention behind the code is “domain tests” and putting our documentation inside the repository so there’s a shared understanding between users, developers and agents.

Extracting intent from code (reading comprehension at scale exactly the skill Yegge says is “draining and beyond the capabilities of most devs”). Reimplementing efficiently on the new baseline, leveraging the new patterns rather than fighting them. Then making judgment calls about what to rescue and what to abandon.

This is, ironically, a task that the latest generation of AI agents are well-suited for: understanding intent and reimplementing, which suggests the solution to the “merge queue” problem might be… more agents. But specialised prompts, skills or sub-agents with reconciliation focus that understand both branches and can perform a “semantic rebase” themselves.

Tooling Gaps

Current git tooling is entirely built for simple code reviews and mechanical merging. git rebase, git merge, even fancy visual merge tools, they’re all operating at the surface textual level. What we need for semantic rebasing to work:

1. Branch intent extraction: What was this branch trying to do? (Commit messages help, but agents don’t always write great ones)

2. Architectural diff visualization: Not just “these files changed” but “the module structure shifted from X to Y”

3. Conflict severity assessment: Is this a Level 1 conflict or a Level 3 conflict? Should I even try mechanical rebase?

4. Intent preservation tracking: When I reimplement a feature, how do I verify I preserved the original behavior?

I’ve been experimenting with some of this in an open source experiment in visual source control, at minimum, being able to see which agent worktrees have diverged and by how much helps you prioritise what to merge first. But the deeper tooling for semantic rebase or “merging meaning” is still nascent across the industry.

Borrow this Prompt

Until better tooling exists, here’s a prompt I’ve been using when I need to perform a semantic rebase. It works well with Claude Code, OpenAI Codex, or similar capable agents that have access to your codebase:

Reconcile this feature branch with master so it can be merged cleanly. Do not change master, only this feature branch. Warning, master has undergone significant structural changes, so this isn't a simple merge from master to reduce the diff. Suggested approach:

1. First, assess the scope — compare this branch against master to understand what's diverged in both.

2. Merge master into this branch.

3. Resolve conflicts, prioritizing master's architecture where there are structural disagreements.

4. Rebuild/rescue feature functionality to work within master's current patterns.

5. Verify the feature still works as intended.

The goal is a PR that:

- Has no merge conflicts with master.

- Follows master's current architectural patterns.

- Preserves the feature's intended functionality.

Note: If the divergence is too severe, it may be faster to cherry-pick the feature's intent onto a fresh branch from master rather than wrestling with conflicts.

The key insight in this prompt is step 4: rebuild/rescue. You’re explicitly giving the agent permission to abandon the original code in favor of reimplementing the intent. And the escape hatch at the end acknowledges that sometimes even Level 3 rebase isn’t worth it, sometimes you need to start fresh with just the intent.

The Uncomfortable Truth

Steve is skeptical that we’ll get guardrails that make this accessible to “average” developers. I share that skepticism. Semantic rebase requires the exact skill that’s hardest and most draining: reading and understanding large amounts of code, in multiple versions, and making judgment calls about what matters.

The developers who get good at this, who can look at a hopelessly diverged branch and quickly extract its intent, assess the new baseline, and reimplement efficiently, are going to have an enormous advantage. It’s not just about prompting. It’s about understanding codebases at a level where you can direct agents effectively.

The swarm is coming. The merge queue is real. And “rebase” is about to mean something much more interesting than git rebase.

I’m making a desktop app for managing Git repositories with AI agent worktrees open source and available for free on Mac, Windows and Linux. If you’re running multiple coding agents and want visibility into what they’re all doing, check it out.

Domain Testing

New software is often tested through a variety of methods such as unit testing, feature testing and integration testing. Recently we’ve been making some major upgrades to the Icehouse Ventures investor portal and we’ve wanted to be sure that the changes to the software don’t change the business logic. I think the style of testing we’re doing might be useful for other teams to explore. We’re calling this new style of testing “Domain Testing”.

Domain testing focuses on validating the correctness of our application’s business rules and domain-specific logic. Rather than testing technical implementation details, “domain tests” verify that the system produces the correct outcomes in realistic business scenarios.

In our venture capital context, this means ensuring that complex financial workflows such as fund management rules or carry waterfall calculations behave as intended. For example, one of our domain tests verifies that when a startup company generates a return, the correct amounts are shared across investors.

All software teams have been doing some kind of “scenario testing” forever in various forms, but we haven’t always had a consistent name for it. Domain testing focuses in on testing a specific business function. The goal is to prove that real-world business rules hold true, using concrete examples that reflect how the software is actually used.

Domain Testing vs Existing Types of Tests

Unit Tests validate individual methods or classes in isolation. Checking that a specific function returns the expected number given certain inputs.
Feature Tests cover entire user-stories, or features potentially including the user interface, controllers and the database, often crossing multiple domains or services.
Integration Tests verify that different parts of the system interact correctly. In Laravel, this might mean simulating an HTTP request and asserting that the controller, ORM, and database all work together.
Domain Tests validate specific business scenarios. They don’t necessarily go through the UI or HTTP layer. Instead, they check domain logic directly in the code. The key difference is that domain tests explicitly encode business intent.

For example, consider this finance module scenario:

Given a fund of $10 million with an 8% preferred return hurdle,
When the fund earns $2 million of returns in its first year,
Then the investors (LPs) should receive their preferred return before any carry is distributed to the fund manager.

This reads like a real scenario. It verifies that the carry distribution follows the defined waterfall (a critical business rule) without getting off track into implementation details.

Test Driven Development for AI

The long established practice of “Test Driven Development” could take on new importance in the era of AI-assisted development. Modern LLMs like Claude and ChatGPT are quickly evolving from simple code auto-completion tools into reasoning agents that can create or update whole new features. But as the scope of AI development widens, the consequences of errors is becoming more serious.

A solid test suite serves as both a safety net and interestingly as a guide when an AI helps generate code. LLMs are powerful but prone to hallucinations or subtle logic errors.

By writing tests upfront (especially Domain Tests that define expected outcomes) we create guardrails that keep the AI on track. The developer specifies the correct business behaviour in the tests, and the AI must work within those constraints. This turns TDD into a way of “teaching” the AI what we actually want.

Domain Tests as Executable Documentation

Domain tests create a shared language of expectations that both humans and machines can understand. Written in terms of business scenarios using clear language and examples, they serve as executable documentation of what the software should do.

Developers, product managers, and even non-technical stakeholders can read these scenario-based tests and understand the system’s intended behaviour. The test suite becomes a living specification of the domain.

This clarity extends to AI systems too. An LLM assisting you can read your domain tests and see the business rules and constraints of your application. If it proposes a refactor or new feature, you can re-run the domain tests to verify the AI didn’t break any fundamental business rules. Our domain tests encode the business rules in a form that a machine can work with.

Domain-Driven Design

DDD teaches us to model software around the core business domain. In domain testing, we leverage these same concepts. One of the concepts we borrowed from DDD for our domain tests was “inspectability”. Meaning that you should be able to put the system in the ‘test’ state and let a human look at it.

Normal software tests are usually randomised and empheral, not designed for human inspection. Using a specific, repeatable scenarios is like the Kobayashi Maru simulator test in Star Trek, the setup is consistent so you can explore different solutions that achieve the end goal.

Practical tip: We use Laravel’s “factories” and “seeders” to set up our domain scenarios. This way we can quickly spin up a fake Fund with ten fake investors, each with certain ownership percentage, then create transactions to simulate cash flows. When your test reads like a story, you know you’re staying true to the domain-driven spirit.

Behaviour-Driven Development

BDD’s Given/When/Then syntax models test scenarios in a way both developers and business stakeholders understand:

Given: a scenario setup
When: something happens in our system
Then: the result is a predictable output.

This structured narrative helps communicate intent. A finance expert could glance at this test and confirm, “Yes, that’s exactly how the waterfall works.”

You can implement this style in Laravel with PHPUnit or Pest. The key is writing tests that tell a story: set up context (Given), perform an action (When), and describe the expected outcome (Then). For normal tests we use Arrange, Act, Assert which is also fine but slightly less suited to domain tests.

A Practical Way to Calibrate AI and Humans

Looking forward, I think domain tests may become a crucial calibration tool between business intent and AI execution. Think of them as the training examples you provide to a junior developer, except the dev will be an AI.

If an AI proposes a database schema change or generates a new Laravel controller, how do we ensure it didn’t break fundamental business assumptions? Run the domain tests. A comprehensive suite will immediately flag any business rule violations, giving both human and AI rapid feedback.

Domain tests also become a sandbox for business validation. Write a test that sets up a complex fund with edge cases (different fee structures, multiple closing dates), run the domain logic, and use Laravel’s debugging tools to inspect the output. It’s like a flight simulator for our business logic, we can try scenarios out in a safe environment.

Implementation in Laravel

Laravel makes it easy to implement domain testing:

Use model factories to create realistic test data that feels real.
Create dedicated test seeders that load the complete scenario in a repeatable way.
Leverage database transactions or RefreshDatabase traits for test isolation.
Structure tests around your domain services, actions and jobs, not just http endpoints.

Your tests become a place where everyone can see the essence of the application laid out in scenarios, where changes can be vetted with confidence, and where future tools can learn what “correct” means in your context.

Conclusion

Domain testing is a practical way to:

Validate business-critical behaviour with high confidence, if a change breaks fund carry distribution maths, a domain test will catch it.
Communicate intent across disciplines through tests written in business language, serving as living documentation.
Build on the best of TDD, BDD, and DDD without reinventing the wheel.
Prepare for AI-assisted development by creating tests that define boundaries of correct behaviour and logic.

As we rediscover testing principles in the age of AI, domain testing could be a language of shared understanding between humans, software, and intelligent agents. It ensures that no matter how our code is written (by us or by AI) the true intent and logic of our business domain remains solid.

Icehouse Ventures Mobile App Launch

Script from the launch of the Icehouse Ventures mobile application at the Annual New Zealand Startup Showcase at Spark Arena on 21 August 2025. We had some tech issues on the night, but it was great to share what we’ve been working on with so many people, and so far the reaction from users has been great.

Good evening everyone. My name is Peter Thomson, and I’m the CTO at Icehouse Ventures. I have what I think might be one of the best jobs the country because I get to spend my time with all of these great startups we’ve heard from tonight and all of you as investors. It’s like Showcase all year round.

I’m particularly grateful to our early adopters many of whom are here tonight like Maurice Maclaren, Richard Reynolds and Ian Holland. Who’ve given us such great feedback over the years.

At Icehouse Ventures, our greatest strength has always been our community of investors, founders and operators. The great startups coming out of New Zealand can become even more unstoppable with a large & engaged network backing them.

But to be engaged, you first need to be informed. And that’s what we’ve been working on for the last five years with our custom-built Investor Portal. When we started on this journey, there wasn’t any software available that could connect a large network of investors with a diversified portfolio of startups, to deliver an immersive experience, while maintaining institutional-grade reporting and security. It didn’t exist, so we had to build it.

But now it’s time to take things up a notch. We want to supercharge your ability to support these great companies. And to do that, we’re going mobile.

Tonight, we’re proud to introduce the Icehouse Ventures Mobile App (available now on iOS and Android). This new app is your window into the people, ideas, and companies building the future of New Zealand. We’re putting the brightest New Zealand companies in your pocket. With a host of new features, you can be engaged with these great companies, not just at Showcase, but all year round. Let me walk through just a couple of the features before I hand back to Robbie.

First, Discussions and Co-Investment. Imagine getting to tap into the experiences & connections of 3,000 fellow investors. With this app, you can now read Investment Memos on the go, ask questions of the founders and participate in due-diligence discussions. It’s the professional investing experience that we’ve always delivered, made portable.

Second, Notifications. These days, startup investing can move fast. Whether it’s a new round opening up, or a capital call. You don’t want to miss out. And recently, Halter’s follow-on round was over-subscribed within a matter of days. The app will help keep you in the loop.

And third, Show & Tell. If you’re in this room, you already know that there are great companies, doing great things here in New Zealand. But not everyone sees what you see. We want to give you a window into their world, one that you can share with your family, your friends, and your colleagues. We want to bring you short, sharp videos direct from the startups so you can stay up-to-date and share their stories.

What I love most about this asset class is how it can inspire the next generation, Our seven year old, Isabelle has recently started getting interested in tech companies and it’s not because of the TVPI or the IRR, it’s because she and I started watching videos together about what the companies are up to. She saw when OpenStar first sparked plasma in Wellington. And she came along for the ride along as Dawn Aerospace took off for space. This isn’t doom scrolling, it’s a front-row seat to history.

Our growing tech platform is built to give New Zealand an unfair advantage. And pursue our mission of making investing in Kiwi startups: transparent, engaging and rewarding. The mobile app was built in-house by our Principal Engineer, Ian Patel and it runs on same core system that powers our main Investor Portal. So we all benefit from the years of hard work by Harry Fakir, Logan Gubb, Nikita Deva, and the rest of the Icehouse Ventures team.

So tonight, we invite you to download what we believe could be a world-first: The chance to have an entire VC firm in your pocket. Please, use the app to amplify the stories of these great companies within your own networks, because the startups are already doing great things, and with your backing, they can be truly unstoppable.

You can watch a clip from the live stream of the presentation on stage here (5 mins):

Laravel for Business Professionals

As technology becomes central to modern business functions, professionals in marketing, finance, and operations increasingly want to tackle projects traditionally reserved for software developers. Having transitioned from corporate law to marketing and then to software development, I’ve gathered tips to make the journey into vibe coding easier and more enjoyable.

Modern AI tools significantly lower the barrier to entry for coding, but there is still a learning curve to being productive in a business setting. My goal here isn’t to turn you into a full-time software engineer, instead the goal is for you to use AI to better understand and work with complex business systems. You can use modern AI coding tools to explore, tweak and build business workflows in hours that would have traditionally taken weeks to implement.

Why Laravel?

Beginners and non developers are often steered by AI toward JavaScript frameworks like Next and React, or Python for data science. I think this is a mistake because:

PHP has 20 years of open-source history, giving LLM models rich context for solving any business problem you encounter. The training examples and content for Laravel apps are often practical B2B SaaS in complex industries like finance, healthcare and manufacturing. Laravel is used by Apple, NASA, Ferrari, DHL, Square Payments, The New York Times, Marvel and OpenAI along with thousands of SaaS startups and in-house custom business applications.
Laravel is a powerful framework that includes robust authentication and database setup out of the box—features that beginners often struggle to implement securely.
PHP excels at rapid prototyping. Plus, if your business has an in-house SaaS platform, there’s a good chance it’s built in Laravel. It makes more sense to learn Laravel from the start rather than coding everything in React only to switch languages later.
The fundamental model of Laravel with MVC, database and logic layer makes it the preferred choice for a lot of SaaS startups, in-house tech teams and digital agencies building rapid prototype software for clients.

Personally, I’ve fallen in love with Laravel because of the helpful community and the focus on clean, minimalist code. The framework is magical for taking complex business domains like investment, finance, education, health or other industries and building software that solves real business problems fast. With AI tools improving rapidly, real code is rapidly replacing low-code tools as the best way to spin up software to streamline business processes.

Every day I’m thankful that we made the call to build the Icehouse Ventures in-house investor portal in Laravel because we have complete flexibility to add features and customisations that suit our exact business model (a large and diverse network of investors making long-term investments into a widely diversified portfolio of tech startups). Using Laravel for the last five years has helped us scale to become the largest and most active Venture Capital firm in New Zealand. Having custom software has allowed us to build investor and founder support functionality, data analysis, and advanced automations that no other VC firm has access to.

Laravel has robust tooling for solving business problems such as custom CRM systems, automating workflows, modelling complex business processes, and integrating with third party APIs data sources. Imagine Excel, HubSpot, Salesforce, Zapier and Notion all in one place and with complete freedom to wire things together in ways that suit your exact business.

Setting up your machine

To start using Laravel you’ll need to set up your machine. Hardcore engineers spend most of their time on the command line for tooling and setup. One of the things that helped me transition into development and suits my big-picture desire for an overview of what’s going on in a system is to use a lot of GUI or visual tools. I find that visual tools make it much easier to understand how a Laravel application works and how to make changes. There are a few key tools that will help you get started:

Version Control: SourceTree

Version control is like a giant upgraded version of a word processor’s ‘track changes’ feature. Full time software developers use version control systems to make sure that they can’t lose their work and that multiple people can work on a project at the same time. It’s useful to have a version control tool on your machine so that you can see the other branches of code and it provides a simple place to make forks of code and to review your changes.

Github is where your company’s code base is most likely contained. SourceTree is a great git client that provides a visual interface for managing your codebase. It makes it easy to commit, push, and pull changes, as well as resolve merge conflicts. Version control is essential when working with AI code tools because it lets you experiment without breaking the main codebase.

Database: TablePlus

A relational database is like a giant spreadsheet with lots of tabs and links between the rows. The database is a key part of a modern web application so you’ll need a way to access your local copy of the database and to see what’s going on. Sequel Pro and TablePlus are both excellent visual tools for accessing a local database so you can see the changes that your application is making. You’ll set up your application’s database later in the process, but having a database viewer set up early will help you debug things and access the database manually as soon as it’s loaded.

Text Editor: Cursor

An integrated development environment is like a word processor specially designed for software development. I personally use Sublime as my text editor for its speed, calm interface, and minimalist design. However, for business professionals accessing their company’s codebase, I recommend Cursor. It combines VSCode’s benefits (plugins and customizability) with powerful integrated AI support.

Cursor’s AI support has several evolving layers, and it’s worth understanding how each can help you engage with a codebase:

Tab / Autocomplete Mode – Works well with existing Laravel code to add small features and tweak the wording on web pages.
Chat / Ask Mode – Great for exploring the code without making unnecessary changes.
Agent / Edit Mode – Modern LLMs can make significant progress on building new functionality in a Laravel app. But they need careful guidance and clear instructions.
Bug Fix / Pull Request Mode – This allows you to review changes and do quality control.

Cursor Plugins

There are a few things you can do to set up Cursor to work really well for Laravel development:

Laravel – The official VS Code plugin helps Cursor to understand Laravel code.
PHP Intellephense – This is what allows you to click through different functions and see the context for the code.
Back & Forth – This adds a ‘back button’ to the top of the editor window which is awesome for navigating around the code base.
Duplicate File – A better copy/paste that makes the sidebar faster for duplicating files (which you’ll be doing a lot of if you’re starting out).

Cursor AI Setup

There are several things you can do to get the most out of modern AI support:

Add a Cursor rules file to your project if there isn’t already one. This should contain some context on the application and a style guide.
Add links to the Laravel documentation to your Cursor “docs” setup. I use the secret Laravel Illuminate API docs which are a machine readable version of the human Laravel documentation.
Like with other advanced business projects it’s worth chatting with an LLM before starting work to make a plan and an outline. You can add these to Cursor by adding a file such as “project_plan.mdc” (markdown format) to the home folder of your project. Then add that to the context when asking the AI for help with specific tasks.

Virtual Machine: Herd

Laravel has several methods for getting a local copy of a code base running on your machine. Docker and Valet are both excellent options but there days Laravel Herd is the fastest way to get up and running. The virtual machine is what allows the application code that usually powers a website to run locally on your own machine without the internet. You can access the website using a normal web browser but instead of calling the internet, it just calls your local machine.

Scratchpad: Tinkerwell

One of the tools I wish I’d had earlier in my journey was a way to run tiny blocks of code without having to change the whole application. Tinkerwell is a tool that lets you write standalone php code and run it with the context of your Laravel application. It’s rocket-fuel for experimenting with random ideas. For example, I recently used Tinkerwell to loop through our portfolio and analyse the gender balance of founders without needing to write permanent code or do a pivot table in excel.

Getting Started: Laravel Starter Kits

The Laravel Documentation has good examples of how to create your first Laravel application. Personally I’d suggest choosing a simple first-party Laravel Livewire starter kit with Tailwind. There are lots of third party starter kits with React, Vue and other front-ends but Livewire keeps things simple. The official Laravel documentation has a great step-by-step guide to seeing up your first Laravel application.

Laravel Cloud provides a fast and easy place to deploy your first application if you need to share it with other people for testing. There are also lots of great resources on how to deploy a Laravel application to AWS and other web hosting platforms.

Key Concepts

There are a few key concepts that really help when experimenting with a code base and when discussing project with your development team.

Model View Controller

The Model-View-Controller (MVC) architectural pattern is a fundamental concept in Laravel. It separates the application logic into three interconnected components: the Model handles data management, the View manages the user interface, and the Controller acts as the intermediary, processing user input and coordinating the flow of data between the Model and View. Think of MVC like a restaurant: the kitchen (Model) prepares the food (from ingredients like the database and any APIs), the waiter (Controller) takes orders and delivers food, and the front of house dining area (View) presents the meal.

Relational Databases

Relational databases are the backbone of most Laravel applications, providing a structured way to store and retrieve data. Familiarizing yourself with concepts like tables, columns, rows, and relationships will help you understand how to model your application’s data and leverage Laravel’s powerful Eloquent ORM (Object-Relational Mapping) to interact with the database. This knowledge will empower you to create robust data-driven applications that can scale and adapt to your business needs.

Database Seeding

If you are starting out with a new application to experiment or your business is in an industry where sharing production data is prevented for privacy reasons then it may be better for you to use synthetic data. Most teams will have a masked-data dump or a test database available but it’s worth understanding the concept of Seeders in Laravel as they allow you to create your own test data. Seeders are a command that creates multiple fake but realistic rows in the database and links them together. Using fake data makes it much safer to test new ideas.

Test Driven Development

Laravel has automated testing out of the box. If you are building a new feature or a proof of concept then adding automated tests is a great way to guide the AI and to prove to the rest of your team that you’ve thought through what you’re trying to achieve. I use a lot of “smoke tests” which means if you try the thing using the happy path (all data in place and doing the main thing the page does), does it work or does it smoke / catch fire when you turn it on. LLMs are great at generating tests and knowing that the tests pass is a good way to check the AI’s work.

Proof of Concept

The concept of minimum viable product comes from venture capital and is a great thing to work towards. But if you’re vibe coding it’s more sensible to aim for a simple “proof of concept” which is code that isn’t intended to be ‘viable’ as in secure, performance optimised and robust enough for production. Instead, a proof of concept is intended to demonstrate the functionality you want in a proposed feature and to help visually communicate across teams. Traditionally this would have been done with paper sketches, prototype or design tools. But with rapid AI advances it’s often useful for business users to have a go at exploring the proof of concept themselves.

Being a team player

If you are working in an existing code base there are some unspoken rules that can help you be a good citizen. AI can allow you to understand, modify and add to a Laravel application very quickly. But it’s worth playing nicely with your existing development team (if you have one, or might hire one in the future).

Make the smallest changes possible (don’t let the AI run wild and re-write the entire code base as it makes things hard to review). Stay focused on one proposed feature or idea. (Doing too many things in one branch can confuse the AI and the humans you have to collaborate with).
Ultimately, product teams do much better with “user needs” as a brief than a proposed solution because often the best solution is deeper in the architecture of a problem or root cause. So don’t just make a proof of concept and say “here just implement this”, instead use the POC as a starting point for a conversation about what you are trying to achieve and why it’s important to the business.

Problem Solving

For a non technical professional exploring code one of the key things I learned was to slow down and read the documentation and any error messages. They may look confusing, but Laravel’s error messages are carefully crafted to guide you but it takes real effort to slow down, read them methodically. The error messages are also gold for pasting back into the AI to help debug.

The journey

I got started on the journey from lawyer, to marketer, to software developer (and now Chief Technology Officer of the product team at a Venture Capital firm) by simply making small changes to an existing code base. There is certainly a scenario where AI replaces the need for software developers entirely, so learning to code is a waste of time. But I think it’s more likely that AI allows non-technical subject-matter-experts (that’s you) to meaningfully engage with code in new and exciting ways that opens up the profession to thousands of people from diverse backgrounds and mindsets who can bring new best practises and new solutions. There’s never been a better time to start coding.

Digital Transformation for SMEs

I spend most of my time at the coal face of new product development inside tech startups. But I’m occasionally called on to help with the broader application of technology throughout a medium-sized or larger organisation. I love seeing how improving their digital tools and systems can make an entire organisation more customer focussed.

Some digital projects only impact one part of the overall customer experience, but these days, any good software project should really consider the wider context of the entire organisation and the whole customer experience that they deliver.

Different company sizes approach digital transformation differently

I’ve noticed that digital transformation projects can be very different in a small to medium sized organisation. Corporates, startups and mid-sized SMEs handle digital transformation and customer experience innovation very differently:

In a corporate there are whole teams dedicated to technology and the connections between functional departments. While there is a lot of bureaucracy, digital transformation and customer experience projects are feasible inside a corporate because they can throw resources at a problem.
In a small business or startup, the whole team is closely enough connected that cross-functional collaboration is inevitable. While resource constrained, the ability to implement change quickly makes startups fast to adapt to changing circumstances and customer needs. They also often have the advantage of dedicated internal software developers, digital marketers and operations specialists with deep technical systems experience.
Good honest medium-sized SME businesses can be the teenagers of adopting digital technology. Big enough to have departments with competing goals and seperate tech systems. But small enough to be resourced starved and unable to invest in major organisational change projects. Digital transformation is hard for SMEs.

Icehouse Ventures is a small, independent rogue team that spun out separately from the Icehouse several years ago. I’m now the CTO of that business and we effectively operate as a tech startup ourselves with dedicated marketing, operations and software development capability. But it wasn’t always like that. And the wider Icehouse (in particular the SME learning & development business) has been through a genuine company-wide digital transformation over the last two to five years. There are several lessons that we’ve learned at the Icehouse in pursuing our own digital transformation and in helping other medium-sized New Zealand businesses with adopting digital technologies better across their whole business.

Digital technology maturity scale

Digital transformation is simply a description of the broad adoption of digital technologies throughout a business. Digital transformation is best measured by how connected together a customer’s experience is with the business. There are several levels of maturity in a company’s gradual digital transformation:

Disconnected Experiences: At level one, every business system is separate and siloed (or possibly offline entirely). For example, it’s annoying for customers when a store’s e-commerce website can’t show whether a particular branch has stock on a particular product because the stock management system doesn’t talk to the website CMS. Or when you lose your receipt for a warranty claim and the loyalty card system won’t talk to the warranty claim software.
Connected Experiences: At level two, a company’s various internal systems are separate but are starting to be connected by syncing tools and APIs. This starts to allow for more connected experiences. For example, an e-commerce order can be re-routed easily to in-store click & collect. Or a forgotten loyalty card can be easily looked up using a phone number.
Seamless Experiences: At level three, a company’s systems are so well integrated that they can be navigated by the customer just as easily as internal staff. At this level we see self-service customer portals, hybrid in-store and on-line checkouts, and in-store payments collected by a self-service mobile app.

Customer Experience Canvas

The tool I used to map and diagnose digital customer experiences throughout the full customer lifecycle is the Customer Experience Canvas. The CX Canvas combines a pretty standard marketing funnel (based on the AIDA model of awareness, interest, desire and action) with a CX Flywheel (similar to the one proposed by HubSpot with stages for acquisition, activation, retention and referral).

There are several potential layers to the canvas depending on the project and intended application:

Experience: The surface layer of the funnel and circle can be used to map the digital touchpoints a customer interacts with throughout their experience of your product. Making these experiences more connected and efficient is a key part of digital transformation.
Data: The same canvas can be used at a deeper level to map out the data used to measure and track the experiences. The metrics we use across the whole lifecycle are based on Dave Mclure’s ‘pirate metrics’ (so called because the acronym is AARRR): Acquisition, Activation, Revenue, Retention and Referral.
Technology: Even deeper, the canvas can be used to map the technology stack and systems integration work required to deliver a seamlessly connected customer experience. This layer looks at the syncing tools, triggers & events and APIs needed to make the whole system work together.

Agile Project Prioritisation Matrix

In 2001, as a reaction to traditional engineering project management techniques (that had been optimised for construction projects), a group of software developers proposed the ‘agile manifesto’. This approach to software development prioritises speed, simplicity and efficiency. There are lots of tools and techniques from agile that can be applied to an organisation wide push for digital transformation.

I’ve found that most companies undertaking digital transformation end up with a giant todo list and no practical ways to have shared conversations about prioritisation. One of the best tools to reach agreement on prioritisation is the Agile Prioritisation Matrix.

When considering a whole of company digital transformation it can be an overwhelming task and it’s hard to know where to start. The agile project prioritisation matrix breaks projects down by:

Impact: Potential return on investment, improvement in customer experience, etc
Effort: Likely expense, time and complexity of implementation.

Projects that are high impact and low effort are quick wins and should be done first to build momentum. High impact and high effort projects are called ‘epics’ and are important to tackle but take time to finish. Whether easy or hard, lower impact projects should be avoided where possible.

Digital Transformation Checklist

Having mapped the customer experience and prioritised the key projects, it’s also worth checking that you have all your basic tools in order so nothing gets lost. Boiling all the strategy down, I’d still suggest checking these basics are in place:

Marketing: Website Analytics & Email Newsletter metrics.
Sales: Customer Relationship Management System.
Production: Invoicing, production and shipping software.
Service: Customer Feedback System such as NPS surveys.
Operations: File storage, knowledge management and internal instant messaging.

Across all of these, it’s essential that your CRM can act as more than just a sales tool and provides enough APIs and/or syncing tools to eventually act as a centralised customer data platform. Because in the end, having your customer data centralised in one place is the most important part of providing a seamless digital customer experience.

You can learn more about digital transformation in a podcast I did with Bryar Stewart from the Icehouse team:

Using JavaScript with Laravel through Inertia and Livewire

For the upcoming Icehouse Ventures investor portal we chose to build the application using Laravel, which is a php framework. Frameworks like Laravel speed up the development process by providing a lot of the scaffolding that you need for a modern web app.

Mockup of the upcoming Icehouse Ventures Investor Portal.

We started off looking at using off-the-shelf tools such as venture capital fund management software and various online angel network platforms. But we couldn’t find any tools that would allow us to provide combined reports that showed a consolidated view of both direct angel investments into a company and indirect fund investments into the same company through a fund the investor was a part of. Investors told us that this was a mission-critical feature so they could evaluate their effective exposure to particular startup companies in their portfolio.

We also evaluated a range of other low-code and no-code solutions such as Salesforce and various template-based databases and website builders. These were ok, but couldn’t handle the depth of complexity investors wanted such as calculating IRR over long time periods, exporting PDF statements and ranking portfolio performance against other investors.

Laravel uses the classic Model-View-Controller architecture.

In the end, we chose php and in particular Laravel because of the robust stability of a MySQL database and the power of the Model-View-Controller approach to the code structure. MVC is a common pattern used in enterprise architecture to build scalable and stable software systems, the key elements are:

Model – A data model that manages your database and represents data as objects that can have relationships with other objects. For example, we have a model for Users and a model for Companies in the investor portal.
Controller – Traffic controllers that manage how data moves around your application. Controllers fetch data from the Models and send it to the Views. In Laravel, the controllers do a lot of heavy lifting in the background such as security, permissions, sorting and filtering.
View – Templates that render html and CSS for the end-user to see what you want to show them. Laravel uses a php and html template format with no JavaScript interactivity by default.

Adding JavaScript to Laravel

As much as I love php, we wanted to provide investors with a modern app-like experience. To do this we needed a modern JavaScript framework such as React (from Facebook), Angular (from Google) or Vue (an open-source JS framework). I chose Vue because it’s popular in the Laravel community, not owned by a giant tech company and is the fastest to learn for a non JS developer like me.

There are several approaches to getting front-end JavaScript frameworks to work with back-end applications like Laravel:

Approach	Advantages	Disadvantages
Single Page Application with API – The traditional approach has been to build the JS front-end as a single page application and feed the data through to the app using a private API.	By keeping things separate, it’s easy to focus on one thing at a time. Back-end developers can work on the back-end code and front-end developers can focus on the front-end code.	My experience with SPAs was that I wasted a lot of time keeping the API and the front-end talking to each other. Frustrating points included login tokens and data-table filtering. In a small in-house tech team there’s no such thing as separate back-end and front-end teams, we’re all full-stack by necessity.
Livewire – This approach allows you to use little bits of JavaScript inside your normal php templates.	It’s cool to have php everywhere and JavaScript only where you most need it. Like a modern framework approach to JQuery.	The disadvantage of Livewire is that it’s still mainly using php not JavaScript, so it doesn’t have the app-like feel of an SPA. It’s also not full-on best-practice JavaScript using Vue or React so you miss out on the Vue and React templates and resources.
Inertia – This is a new way to use JavaScript inside the MVC framework of a php app. The Model and Controller are in php and the View is in JavaScript.	Best of both worlds. Inertia lets php do what it does best (databases, models, relationships, security, etc) and JavaScript can do what it does best (render the front-end interface and provide interactivity).	Not technically an SPA. Requires some finesse to make it feel fully app-like and the progress loader is a bit clunky. Inertia puts JS right inside your php monolith so you now have a multi-language code base that might feel weird to some developers.

Livewire is a new method for using JavaScript inside a php template.

Laravel 8 was released recently and now includes both Livewire and Inertia as options for the default Laravel user interface templates (called Jetstream). This is exciting because it will expose these two new approaches to more developers. But it’s been confusing for a few developers who are used to thinking of JavaScript as a different world from php.

Inertia allowed us to use Vue JS in our Laravel app.

On balance, we opted to use Inertia for the Investor Portal because it kept our code base all in one place and allowed us to move fast and change things quickly based on user feedback. I’ve already had dozens of moments where we wanted to make a change to the way that something is displayed in the portal. It’s a true joy to be able to make a quick change to the Company model, flow it through the Direct Investments controller and have it pop up in the investor portal Vue file all in the same code-base, with easy Laravel debugging and easy feature-testing and front-end testing. By having Vue running inside Laravel I’ve upskilled quickly on JavaScript without having to go all-in on complex JS routing and data manipulation.

Notice the simple call to Inertia from the Controller. Just like a Blade template.

We also went for Tailwind CSS instead of the more established Bootstrap CSS framework. Tailwind is a utility framework approach which means that instead of single giant templates in CSS with little HTML tags you just layer lots of little HTML tags onto an element to make it look the way that you want. It seems messy at first but once you get used to it, it’s life changingly fast. Using Tailwind, Alipne JS, Livewire and Laravel is called the TALL stack and I’m calling Vue, Inertia, Tailwind and Laravel the VITL stack. (Some people prefer the name LIT for this stack but I think Vue is a vital part of what makes this approach so awesome).

Building software in-house is an unusual move for a Venture Capital fund but Icehouse Ventures has a unique approach that combines the scale of the Ice Angels network and the depth of major funds like IVX and Tuhua. Globally, the venture capital industry is being quickly re-shaped by increased investor demands for transparency & reporting and by startup founder demands for faster decision making & streamlined capital raising processes. Technology can be a force multiplier for us and having both php and a modern JavaScript framework like Vue in our toolkit means that we can move faster while still keeping things safe, stable and secure.

Advanced Video Conferencing for Remote Work

Now that everyone is settling into remote working, we are finding that being productive requires more than just having the basics of team chat and video conferencing in place. To generate real economic output in uncertain times you need to be communicating closely with your customers, suppliers and business partners. Experience suggests that there are actually three levels of remote working:

Internal communication and basic connectivity.
Client communication including meetings, events and training.
Productive deep-work including multi-party workshops and brainstorming sessions.

Understanding the type of interaction you want to create will help guide the setup for your meetings and the tools that you use.

Internal: Your IT team will probably already have set you up with some sort of video calling platform. You should check that this video calling tool also includes team chat, calendar integration and external calling as well as internal. This means that you’ll probably want to be on a professional corporate communications platform such as Google Hangouts, Microsoft Teams or Slack. These chat plus video calling tools are great for reducing email and smoothing out daily internal communication. Hot tip: Create a lot of ad-hoc chats with small internal groups around key projects, these are where th actual work gets done (not in the big all-company threads).

Client calls: For small group and one-to-one client calls, I advocate using whatever tool your customer is already used to using. If they use Skype, Zoom or MS Teams then find a way to use whatever they are using because it’ll be familiar and allow them to focus on the content of the conversation. If your client doesn’t have a preferred tool, then you can default to using whatever internal tool you already use because you’ll be comfortable with the tool and can share your experiences with your client giving them a chance to try it out. Hot Tip: Get yourself set up in advance with logins for all the most common video calling tools so you’re ready to go with whatever your clients use.

Large group calls: Video calls with a large group tend to stretch the internal communications tools a bit too far because these tools are usually designed for small internal team meetings. For example, Microsoft Teams only shows four people on screen at any one time. Zoom is becoming the market leader for large group calls and it’s worth getting to know the advanced features of Zoom before you need to host a large call. These types of large group calls are a passable substitute for networking events, professional presentations and team training. Hot Tip: Have a two-person hosting team with one person focused on managing the humans (moderating Q&A etc) and one person managing the tech (such as muting and unmuting people).

Presentations: For one-way presentations to a large audience, there is a whole range of dedicated webinar tools such as Crowdcast, Webinar Jam and Go-to-Webinar. At the Icehouse, we’ve been using the dedicated webinar tool inside Zoom for our Coronavirus Business Support Webinars. The key to good webinar presentations is a lot of practice (especially with guest speakers) and putting a lot of effort into encouraging audience interaction. Hot Tip: Nominate a ‘studio audience’ of three to five people to have their cameras turned on as an audience panel so the whole thing looks more interactive and the presenter has someone other than themselves to look to for feedback.

Zoom Meeting (Notice that everyone is shown in an equal grid.)

Tips for webinars and large meetings

Large format meetings are a great way for people to feel connected when we’re all working remotely and uncertain about the economic outlook. It’s great to hear about other people’s experiences and see how much we all have in common no matter what industry we’re working in. At the Icehouse, our team ran webinars and large format Zoom meetings with over a thousand people in the first week of lockdown and we had to rapidly arrange dozens of private Zoom calls to pivot our coaching and advisory activities. We’ve learned a few hard lessons along the way. Here are a few quick tips that apply whatever type of call you’re running:

Encourage everyone to turn their video on: Most people hate being on camera but having the video on for all participants is vital for making things interactive. Seeing everyone gives the presenter non-verbal feedback so they can see if what they are saying is landing. It also allows the participants to see each other which makes the whole thing more personal. It can also be useful for quick hand signals such as thumbs up and waving to attract attention.

Look your best: The key to decent video is to have the camera at eye level (or above) so put your laptop on a cardboard box or prop your phone up somewhere. It’s also important to have good lighting. Try to have any natural light coming from in front of you rather than behind you. Sitting in front of a window will cast you as a silhouette.

Clear audio: Wear headphones. Even if your computer has a decent microphone and speakers, experience suggests that laptop speakers are more likely to cause an echo and the default laptop microphone is more likely to pick up random background noise from around the house. Even a cheap iPhone headset is miles better than the laptop mic. Personally I use bluetooth airpods because I can easily switch them between my laptop and phone.

Use chat: Most video calling tools also have a group chat feature. Use this for general banter, sharing links and random comments on the topic at hand. The chat is a key part of making webinars and large format meetings seem interactive. People will only use the chat if the hosts and panellists start first so model the behaviour you want to see.

Facilitator: Having a strong facilitator on a video call is priceless. There’s always someone who goes on too long or doesn’t know when to let other people speak. A good facilitator can guide the conversation and keep everyone on track.

Zoom Webinar (Notice that the presenter is spotlighted and the panelists are shown in a strip at the top.)

Advanced Zoom Tools

We’ve been using the Zoom software extensively at the Icehouse and there are a few tips that are specific to the Zoom platform:

Gallery View: Zoom has a button at the top right that toggles between Speaker View (seeing only the person that is speaking at the time) and Gallery View (seeing a grid of videos from all the attendees). The host can toggle between these to set them for attendees. But attendees can override the setting for themselves. Our experience is that Gallery View is more friendly and engaging because you can see everyone at once.

Screenshare: Sharing a slide show is a great way to keep a presentation on track and keep the pace up but in the Zoom software the screenshare takes over the whole screen and hides everyone except the person that is speaking. There’s an advanced ‘side-by-side’ mode that allows you to see the Gallery View during a screenshare but no one ever finds that so we recommend keeping the presentations as short as possible and spending more time on Q&A.

Security: As Zoom has become more popular there have been a lot of press articles about privacy and security concerns about the software. Some of these sound alarming at first but most of them are just hype. My favourite example was a widely reported vulnerability that in practise required an ex-NSA hacker to have physical access to the device to exploit. If the NSA is breaking into your house to hack your laptop, then you probably have larger problems than Zoom.

Privacy: There has been a rise in Zoom Bombing which is the practise of randomly logging into other people’s calls uninvited and causing trouble. The cure for this is to be careful about where you share the links to your calls and to require registration in advance for large public calls.

Moderator: Having a tech person or at least an experienced power-user on each call alongside the facilitator means that one person can manage the conversation going on front-stage and the other person can manage things like chat, people waiting to join, banning any trouble makers and providing support for anyone who can’t get onto the call.

The Zoom Host Dashboard

My final tip is to over-share the links to your calls. Send the link when people first rsvp, then send a calendar invite, then send a reminder one hour before the call. Keep these reminders super short so they don’t annoy anyone.

We will be publishing best practise guides for remote working, video calls and webinars on the Icehouse website shortly along with an updated guide to the best Zoom privacy and security settings. You can follow along with all our Covid-19 support and resources here Icehouse 2020 Covid Support for NZ Small Businesses

Why is building a website so hard?

I’ve been working in technology startups for several years now and I’ve been up close and personal with what it takes to get something designed, built and onto the internet.

During the consulting parts of my career, I helped build plenty websites for clients. But it’s a whole different ball-game when you are in-house and personally responsible for whether or not the site is delivering results. I’ve found that as soon as you’re responsible for the actual business results, your whole mindset towards building digital products changes. For example, I’ve found that all of a sudden usability and simplicity become more important than how things look for their own sake.

I’ve always been fascinated by how things that seem like a nice easy website project can gradually become complex, stressful and expensive. It’s not just the normal “things take longer than you’d expect” effect from all types of project management. Something more profound is going on when building digital products. There are several interesting issues that cause website projects to be harder than you’d expect: Continue reading Why is building a website so hard?

Category: Technology