It began with a very ordinary sentence from our founder:
I wanted a short break from prompting and to plant a few trees.
There was no product brief. We wanted to decide where figs, plums, cherries, walnuts, poplars, holm oaks, lavender, and rosemary could make sense on a family property near Sinj.
The first useful answer was not a planting list. The terrain has cold winters, late frost, summer drought, and a southern section that can hold water after snowmelt. Some species fit naturally. Others need a protected position or should remain an experiment.
Once those constraints were visible, the question changed. Trees could not be planned separately from the house, pool, access road, parking, garden, children’s area, open lawn, service routes, and the wet part of the land. A planting plan had become a site plan.
That was the point at which we stopped trying to solve the problem in a chat and started building a tool for it.
What we built
The input was material we already owned or could legitimately use: a geodetic parcel outline, the architectural concept for the house and pool, our notes about the land, and public visual context for the road edge.
We turned that into a static web application with:
- the parcel represented as measured geometry rather than a decorative background;
- a 2D plan for quick decisions about zones, distances, and circulation;
- an orbitable 3D model of the terrain, house, pool, planting, roads, and activity areas;
- a first-person walk mode at eye level;
- parking, garden, orchard, family, recreation, privacy, and water-management zones;
- desktop and mobile controls, including touch navigation;
- automatic checks for important spatial relationships;
- a release-based production deployment that can be shared through a URL.
The house was not left as a generic block. We reconstructed its main volumes from the project drawings, including the covered terrace, recessed entrance, roof lines, pool dimensions, steps, and machine-room position. The landscape went through the same process: entrances moved to their documented positions, parking was pulled away from the pool, paths were corrected, and vegetation was used where it solved a specific privacy or circulation problem.
The result is available in the Glavice HILLS planner. It is still a planning model, not construction documentation. Its value is that the family can inspect the same proposal in plan, from above, at eye level, and on a phone before committing work on the land.
The first prompt and the deployed model were about 15 hours apart
The conversation started on 27 July at 18:56. The last iteration in this cycle was committed the next morning shortly after 10:00.
That is roughly 15 hours of elapsed time, including research, changes of direction, feedback, sleep, implementation, mobile work, and several production releases. It was not 15 uninterrupted engineering hours.
The speed came from narrowing the problem in working increments:
- understand the terrain and planting constraints;
- define the whole property instead of an isolated orchard;
- encode the actual geometry;
- add 2D and 3D views;
- walk the proposal at human height;
- test it on mobile;
- correct the plan through visual review.
Each version made the next disagreement cheaper. It is much easier to say “that parking is too close to the pool” while looking at a measured model than while comparing paragraphs in a document.
A narrow custom tool can now be cheaper than adapting a broad product
This project also exposed a commercial risk for companies that build planning and visualization software.
We did not use another company’s source code, private data, protected assets, or internal systems. We combined our own project inputs with common web technologies and publicly documented tools. The interaction patterns involved—drawing a plan, orbiting a 3D scene, walking through it, and switching layers—are established software patterns.
What changed is the cost of assembling them for one precise workflow.
A broad product has to support many property types, user roles, billing plans, imports, edge cases, and support paths. Our planner only had to understand this property and the decisions its owners needed to make. That narrower scope let us include local details that a generic product would either miss or require the customer to configure manually.
For a software company, the risk appears when most of the perceived value sits in a reproducible interface over commodity capabilities. A capable team can study the workflow, remove everything it does not need, and build a custom version around its own data surprisingly quickly.
AI-assisted development compresses that work further. It helps with research, code generation, iteration, and testing, but it does not decide whether the southern wet area should be drained, retained, or planted differently. It does not know whether an entrance is wrong just because the geometry compiles. Those decisions still depend on source material, domain constraints, and review.
What remains defensible
This does not mean every software product can or should be rebuilt internally.
The difficult parts of a durable product are usually the ones a screenshot does not reveal: proprietary datasets, accumulated customer context, deep integrations, permission models, operational reliability, network effects, distribution, and years of domain decisions encoded in the system.
Companies whose advantage is mainly a collection of screens should take the change seriously. Companies that own a hard problem, keep earning useful data, and fit deeply into customer operations have a stronger position.
The same distinction matters to buyers. A custom tool makes sense when the workflow is specific, the inputs are controlled, and a smaller system can remove substantial process overhead. A mature product remains the better choice when the hidden operational surface is larger than the visible feature list.
Our job at HILLS Lab is to make that boundary explicit before recommending a build.
Why the next version will be in Unity
The browser was the right first environment. A link opens immediately, feedback is simple, and the same deployment works on a laptop and phone. It let us validate the geometry and the decision workflow before investing in visual fidelity.
We plan to build the next version in Unity for a different set of questions.
Unity gives us more room for terrain detail, lighting, materials, dense vegetation, level-of-detail control, and stable first-person navigation in a larger scene. More importantly, it will let us model time: how young trees grow, where shade falls through the seasons, how different planting phases change the view, and how the property feels from specific paths and gathering areas.
The web planner will remain the quickest shared decision surface. The Unity version is intended as a higher-fidelity simulation layer once the underlying plan is stable enough to deserve it.
What started as a break from prompts produced something more useful than another planting list. It gave us a measured way to discuss the land, and a compact example of how quickly software moves when the workflow, source material, and decision-maker are in the same loop.
If you are deciding whether a constrained internal workflow needs an existing product, a custom tool, or a smaller prototype first, talk to HILLS Lab.