David Dal Busco, the founder of Juno, has managed to put together a trail app by doing what he casually calls “vibecoding.” That’s not a Silicon Valley buzzword — it’s his way of working with large language models (LLMs) like Cursor to write the code, without diving too deep into it himself. The result is a functioning application that lets users view trails, store metadata, save GPS data, and even handle admin-level tasks — all with minimal manual input from the developer.
This isn’t a case study from a product launch or some elaborate marketing push. It’s a tinkering exercise, one that started with the aim of testing out how well AI tools can handle full-stack app building. Dal Busco’s project is a learning tool for himself and others — a look at what’s possible when you rely on LLMs to piece together the moving parts of an app with almost no traditional coding along the way.
The app includes admin authentication, a datastore for handling metadata, and file storage for user photos and GPX data. To make it more interactive and genuinely functional, it also uses serverless functions that calculate and present stats. All of this came together with a surprisingly smooth process, considering that Dal Busco was mostly steering the AI in the right direction rather than writing code himself.
He did mention a few course corrections along the way. Getting the AI to find and apply the right documentation took some trial and error. That’s hardly surprising for anyone who’s ever worked with LLMs for development. Still, once it got going, the overall setup seemed impressively coherent. There wasn’t any hacking around to make broken parts work. The flow was natural, and the output was clean enough to keep the entire structure running.
There are some caveats, which Dal Busco is upfront about. The current version fetches data only on the client side. That’s fine for a demo, but for real-world use, this sort of static data would typically be prerendered to improve performance and SEO. Still, as far as experiments go, this one gets a solid tick.
The serverless functions were one of the more interesting inclusions. Rather than building out a whole backend infrastructure, Dal Busco leaned into the benefits of stateless, on-demand computation. This kept the app lean and flexible, which is ideal for a use case like trail tracking. With photos, trail metadata, and GPX files all sitting in dedicated storage, the functions simply crunch numbers and return results without holding on to any long-term state. It’s clean, scalable, and fairly low-maintenance.
There’s also a sense of creative restraint to the whole thing. Dal Busco admits he didn’t really look at the code. That’s not to say he’s avoiding responsibility — more that he wanted to see what AI could do when left to handle structure, syntax, and logic by itself. His approach was more about feeling out what works than obsessing over every line. If he’d opened up the files, he says, he probably would’ve ended up rewriting everything. That wasn’t the point here.
Instead, the exercise served as a real-time feedback loop for both him and the AI. As he worked with Cursor, he began to see where the documentation needed improving. That’s often one of the more underappreciated areas in open-source projects — solid documentation can make or break how accessible a tool is, particularly for newer developers or those relying on LLMs to guide their workflow. By running through a full build with Cursor and Juno, Dal Busco essentially pressure-tested both the tool and its supporting materials.
Vibecoding, as lighthearted as the term sounds, may become a bit more common in practice. Developers are increasingly working alongside AI to prototype faster and strip away much of the boilerplate that usually clogs up app development. The challenge, of course, is in knowing what to trust and where to double-check. But once that balance is found, the potential for getting from concept to functioning prototype shrinks dramatically.
In this case, the app is focused on trails — letting users engage with mapped routes, attach photos, and view GPS data. While it’s a demo, the structure is solid enough to form the basis for a consumer-facing product. There’s even the backbone of a content system baked in with the metadata handling, and the use of serverless functions suggests it could scale without too much additional effort.
The whole thing is a bit like having a conversation with the future of app development. LLMs are getting better at understanding prompts that involve multi-step logic, dependencies, and context. What Dal Busco did was guide the AI to glue it all together. He wasn’t barking orders or demanding syntax-level perfection — he was nudging the system to think the way he needed it to think, all while staying largely hands-off.
And that’s one of the quieter messages here: AI tooling isn’t about replacing people who know how to build. It’s about speeding up the process, testing what works, and taking the load off things that don’t really need human hands anymore. This sort of “vibecoded” project won’t replace carefully crafted software in mission-critical contexts, but it does make a strong case for using LLMs to sketch out and test ideas without needing a full engineering team or massive setup overhead.
There’s also something refreshingly open-ended about how Dal Busco shares his experiments. He’s not branding this as a breakthrough or slapping a logo on it to launch a startup. It’s just a personal project with clear takeaways, shown publicly to spark ideas and maybe nudge a few tools toward better documentation. The honesty about what works, what doesn’t, and how the whole thing came together makes it feel more like a conversation than a case study.
And while this might not end up in the app store as-is, the underlying approach is likely to stick. As tools like Cursor improve and as LLMs become better at context retention and multi-step reasoning, more developers are going to find themselves vibecoding without even thinking about it. What started as an experiment for one developer might soon be standard practice for many.
For now, this little trail app stands as proof that a few nudges, a working LLM, and some decent documentation can go a long way. No heavy lifting, no ceremony — just a simple product made by asking the right questions and letting the machine do most of the typing. And that’s what makes it interesting: not the complexity, but the fact that it didn’t have to be complex at all.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
🪙 BTC Wallet: bc1pp5kuez9r2atdmrp4jmu6fxersny4uhnaxyrxau4dg7365je8sy2q9zff6p
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
Community Discussion