10.19.2026
Patrick Ahler, senior vice president of growth at Castle Resorts & Hotels, has worked on both the agency and operator sides of hospitality technology. After beginning his hotel career at Aqua and later co-founding Lights On Digital, he now helps Castle turn technology investments into more direct bookings and better returns for property owners. That experience has shaped his focus on how quickly a system can deliver value, who will manage it and what it will cost to maintain.
Those priorities guided the rebuilding of CastleResorts.com, which serves 20 hotels, condominium resorts and vacation rental properties across five reservation systems. Working with a small specialist team, Castle used AI-assisted development to launch the site in under four months at a low-five-figure cost, after considering a $150,000 agency proposal. Ahler reports that revenue per session increased 41% in the first 30 days after launch compared with the preceding 30 days, while the number of users reaching a booking engine rose 182%.
In this Spotlight Interview, Ahler discusses the decisions behind the rebuild, how the team connected five booking systems and where human expertise remained essential. He also explains how Castle is evaluating the early results, managing the platform after launch and adapting its approval processes as development moves faster.
Your background combines hospitality marketing, entrepreneurship and technology. How has moving into Castle’s senior vice president of growth role changed the way you evaluate technology investments? What has surprised you about seeing those decisions from inside a hotel operator?
I got my start in hotels as a marketing analyst at Aqua, a hotel management startup, so joining Castle feels like coming back to where I started, this time after building and selling a company of my own.
At Lights On we operated as a startup, and we learned early to run lean on both cost and execution. Every dollar and every vendor had to earn its place. I’m bringing those same principles into the growth role at Castle. When I look at a technology investment now, I ask three questions: how fast can we get to a working version, who owns it once it’s live, and what does it do for our owners’ revenue.
What surprised me from the operator side is how much of the cost of technology sits in the time between deciding and doing. Agency queues, change requests and handoffs add up. AI is letting management companies rethink a lot of that, and the website was the clearest place to start.
When you think about growth across Castle’s portfolio, how do you balance generating more demand with improving conversion, guest relationships and returns for property owners? Where did rebuilding the website fit within those priorities?
Market conditions decide where to focus first. Hawaiʻi has been in a bit of a slump on visitor demand, which means management companies have to compete harder for the travelers who are still coming. When demand is soft, buying more of it gets expensive, so the better return is converting more of the demand you already have.
That made conversion our first priority. A direct booking costs less to acquire than an OTA booking, so more of that revenue reaches our owners. A direct guest is also our guest, with a relationship we can build on for the next trip.
The website sits at the center of all of it. Paid media, search, email and AI assistants all send people there, and if the site doesn’t convert, every other channel underperforms. Rebuilding CastleResorts.com was the first move because it improves the return on everything else we spend. In the first 30 days after launch, revenue per session rose 41% on fewer sessions.
Before choosing a development approach, what were the most important problems you wanted the new CastleResorts.com to solve? What did guest behavior, property teams or booking data reveal about where the previous experience was falling short?
Three problems. First, the path from interest to booking. We manage 20 properties across five reservation systems, and the old site made guests work too hard to get from a property page to rates and availability. Our north star was simple: property page to booking engine. Second, consistency. Property content lived in different places and in different shapes, so page quality and depth varied from one property to the next.
Third, speed of change. The old site lived entirely in code with no CMS, so every change, even a new offer, needed a developer. In a soft market you can’t wait on that. The early results confirm the old site was leaving bookings on the table. In the first 30 days after launch, users reaching the booking engine were up 182% compared with the 30 days before.
You’ve described an afternoon prototype as the starting point for this project. What did that prototype demonstrate, and what evidence did you need before deciding that an AI-assisted approach could support a production platform for the full portfolio?
In late March we were weighing a $150,000 agency proposal for the new site. Before committing to it, I spent an afternoon building a homepage prototype with Claude. It had island-based navigation, every property mapped to its island, a kamaʻāina rates callout and a section for prospective owners.
The code was disposable. What it proved was that the cost and time of building a website had changed, and most of the industry hadn’t priced that in yet. A credible design direction took hours, and I could describe a change and watch it happen on screen.
Before committing the full portfolio, I needed to know whether a professional team could build it to production standards on a mainstream stack, whether our own team could manage content without a developer in the loop, and whether booking would work cleanly across all five reservation systems.
The stack answered the first two. Next.js, Sanity and Vercel are mainstream, and AI tools work inside them easily. For the third, our property teams pulled together documentation for every booking engine, which gave our development partners what they needed to route each search to the right one.
“AI-native development” can mean very different things. What did it mean in this project in practical terms: which parts of research, design, coding, content migration and testing changed. Which responsibilities remained firmly with people?
For us it meant AI did the production work at every stage, and people made every decision.
For design, we started from a working prototype. Negi Studio designed in Figma and Paper and built the design system in code on shadcn and Base UI. For coding, Negi Studio mainly used Codex, and ZenShin used Claude Code and Cursor, across components, page templates, migration scripts and testing. Linear kept planning and context aligned for the people and the AI tools.
For content migration, AI pulled content from the legacy site and property materials, restructured it into the new fields, flagged gaps and conflicts, and drafted consistent descriptions across all 20 properties. Months of manual entry became weeks. After launch, our team edits in Sanity, and AI tools connect to it through MCP, so I can update the site by describing the change.
People owned the judgment calls: design and brand, accuracy of room types and policies, every booking test across all five engines, cross-device QA, accessibility, redirects from the old site and final sign-off on every page.
Castle chose a small specialist team rather than a conventional agency engagement. How did you select the people involved, divide responsibilities and identify the expertise that AI could accelerate but not replace?
We kept it small on purpose. Gage Minamoto and Negi Studio led design and front end, Ephraim Botulan and ZenShin owned the CMS, back end and integrations, Sassato advised on marketing and creative, and our internal team owned decisions and content.
We looked for people who already build with AI every day and who would own the outcome with us. A small team also meant fewer handoffs, and handoffs are where timelines usually slip. AI sped up the production work. It couldn’t supply design taste, booking engine know-how, launch engineering or knowledge of our properties, so those were the seats we filled with people.
The announcement contrasts a launch in under four months at a low-five-figure cost with much larger conventional proposals. How should another hotel operator make an apples-to-apples comparison that includes internal staff time, scope, quality assurance and ongoing maintenance rather than just the initial development bill?
Compare total cost over several years at matched scope. The initial bill is the smallest part of the picture.
Start with scope: the same number of properties, templates and integrations, and the same accessibility and SEO requirements. Count internal time too. Our team spent real hours on decisions, content review and testing. For QA, ask who tests booking handoffs, devices and redirects, and whether it’s in the price.
Look at the cost and turnaround for every update after launch. This is where the gap widens. Our team now makes most content changes instantly in the CMS. For hosting, licensing and lock-in, consider what you pay every year and what it costs to leave. Then there’s time to value: every month a better-converting site is live is worth money.
Our build came in at low five figures and launched in under four months. The agency proposal we had in hand was $150,000. AI has collapsed the cost of building a site, and a lot of agency pricing hasn’t caught up.
The site brings five reservation systems into a single search and booking experience. What was the hardest part of making that journey feel coherent for guests while preserving accurate property information, travel dates and availability across different systems?
The hardest part was keeping it simple for the guest. Guests browse, pick a property and dates, and we route them to the right one of five booking engines. They just book.
Our property teams gave us documentation for every engine, covering URL structure, naming and parameters, plus the promo codes behind each offer. With that, ZenShin built one booking form that serves the correct engine for whichever property the guest picks, and Negi Studio built three or four versions of the booking widget so a guest can start a booking from wherever they are on the site. We checked room names and policies against each engine, so what a guest reads on our site matches what they see at checkout.
Offers carry through too. When a guest starts from a special’s landing page, like our Military Discount, a script adds that promo code once they choose a property and dates. Engine URLs and promo codes are managed in the CMS, so non-technical staff can launch an offer without a developer.
It’s working. In the first 30 days, users viewing room rates were up 171% compared with the 30 days before launch.
Your portfolio includes hotels, condominium resorts and vacation rentals in different destinations. How did you decide which parts of the digital experience should be standardized and where the differences between properties and accommodation types needed to remain visible?
Our rule: standardize anything that helps a guest compare and book, and keep anything that helps a guest choose.
Standardized: navigation, search, page structure, the content model behind every property and the path into booking. A guest moving from a Waikīkī hotel to a Kauaʻi condo resort should know exactly where everything is.
Kept distinct: what kind of stay it is and what that means for the guest. A hotel room, a condo with a full kitchen and a vacation rental where every unit is different set different expectations, so those differences show up clearly on the page. Island and neighborhood context, photography and each property’s character stay visible too. Those are the reasons someone picks one place over another.
AI can accelerate content production, but incorrect amenity details or booking information can create real guest-service problems. How did you establish a reliable source of truth and a review process for the content that moved onto the new site?
We never let AI be the source. It moved and reshaped content from sources we trusted: the legacy site, property materials and each booking engine’s documentation.
What it did especially well was flag every place those sources disagreed, so people knew exactly what to check. Then people reviewed every property, with room types and policies checked line by line against the booking engines, since a mismatch there shows up at checkout and costs you the booking.
After launch, code changes run through version control in GitHub and content edits keep a revision history in Sanity, so we can see what changed, when, and roll it back if needed.
You’ve noted that content, coordination and human decisions became bigger bottlenecks than the technology itself. Can you share a specific example, and explain how you would organize approvals or decision-making differently on the next project?
Once AI compressed the build, the slow parts were people. We started without a strong brand kit, so Negi Studio had to fill those gaps while building. When requirements changed mid-project, they had to go back and clean up design decisions that were already in code. With two teams building in the same codebase, keeping branches and versions coordinated took real attention too. Design QA ended up running a little over a month. None of that was a technology problem.
Next time I’d organize around decisions from day one. I’d lock brand and content direction before the build starts, since the build is no longer the long pole, and name one decision owner per area at kickoff, with authority to say yes. I’d set review windows up front, so feedback comes in on a schedule, and batch approvals by property, so a reviewer signs off on a whole page at once.
Our earlier Viewabl coverage focused on website accessibility. How did that experience inform your approach to accessibility on Castle’s new site, and how did you distinguish automated checks from the testing needed to understand whether guests could actually complete key tasks?
Accessibility was part of the build from the start. We built it into the shared components, so fixing something once fixes it on every property page.
Automated scans catch the mechanical issues, like missing labels, low contrast and broken heading order. They can’t tell you whether someone can book a room. So people tested the key tasks by hand: searching, choosing a property, picking dates and reaching the booking engine.
The checkout runs inside each third-party booking engine, so part of the guest journey depends on our vendors’ accessibility too. We treat accessibility as ongoing work and keep reviewing it as the site changes.
When AI helps write code, a functioning demonstration is not the same as a dependable booking platform. What testing, security review and launch criteria gave you confidence to go live, and how did you prepare for failures or unexpected guest behavior?
A demo only has to work once. A booking platform has to work for every property, every engine and every device, every time. Before launch, people owned booking tests across each booking engine, cross-device and cross-browser QA, redirects from legacy URLs so search rankings and saved links carried over, and performance testing.
Design QA alone ran a little over a month. Moving fast meant the first builds missed edge cases, and that month is where we caught them, including a full day near the end on small bugs we wouldn’t have gotten to otherwise.
On security, the biggest decision was structural. Payments and guest data stay inside the booking engines, so the site never handles card data, which keeps our exposure small.
We launched on August 26 and spent the rest of the month fine-tuning. Every release deploys from GitHub, so if something breaks we can roll back. The site is faster too: Largest Contentful Paint improved 54%, averaged across mobile and desktop, compared with the period before launch.
Owning the platform gives Castle more control, but it also creates long-term responsibilities. How are you approaching documentation, maintenance, vendor dependencies and continuity so the business can keep improving the site without becoming dependent on a single developer or tool?
We set it up so no single person or tool is a point of failure. The code is ours. It lives in our GitHub, built on Next.js and Sanity and hosted on Vercel. Those are mainstream tools any competent web team can pick up. AI can work inside it. That was a deliberate choice. Proprietary platforms keep AI on the outside. Open code and a headless CMS let any AI tool work directly in the site, so we’re never locked into one.
Non-technical staff run the day to day. Content, offers and promo codes are managed in the CMS. Most updates are instant, and anything that needs a developer turns around the same day. Our partners know the system. Negi Studio and ZenShin built it, and our internal team works in it every day.
The launch materials emphasize discoverability through both search engines and AI assistants. How are you adapting your content and technical approach to those channels, and what would count as meaningful commercial success beyond increased visibility or traffic?
We built the site to be read by machines as easily as by people. Every property has the same clean, structured content, with schema markup, fast pages and plain answers to the questions travelers ask. That makes it easier for search engines and AI assistants to understand us and describe our properties accurately.
The early signal is good. In the first 30 days compared with the 30 days before launch, organic search revenue was up 42% and revenue from AI assistant referrals was up 19%, with engagement from those visitors rising from 62% to 78%.
Visibility only matters if it turns into bookings. The measures we care about are revenue by channel, revenue per session and the share of our bookings that come direct.
Now that the site is live, which measures will tell you whether it is improving the business? How will you separate the effect of the new experience from seasonality, changes in marketing spend and differences in demand across properties?
The measures that matter are revenue per session, conversion rate, booking engine reach, average booking value and direct share of total revenue, and ultimately revenue for each property’s owners.
The early read is strong. Comparing the first 30 days after launch with the 30 days before, revenue per session was up 41%, conversion rate up 18% and average booking value up 16%. Revenue grew on fewer sessions, so the site is converting more of the traffic it gets.
Thirty days against the thirty before is only a starting point. To isolate the site’s effect, we’ll compare the same period year over year, property by property. We’ll weight rate metrics like conversion and revenue per session, which hold up when traffic swings. We’ll watch paid channels at comparable spend. Paid search conversion rate was up 50%, which says the same dollars are working harder. We’ll reconcile site analytics against booking engine data and read properties with different demand patterns separately, so one strong market doesn’t carry the average. We’ll have a cleaner read once we can compare the same season year over year.
What is one promotion, content update or booking-experience experiment that Castle can now execute more easily? How do you decide which experiments deserve attention and when a promising result is strong enough to justify a wider rollout?
Promotions. Offers, their landing pages and the promo codes behind them are managed in the CMS, so our team can launch one without a developer. Our Military Discount, for example, has its own landing page, and the promo code follows the guest into whichever booking engine they land in. On the old site, which lived entirely in code, every one of those changes needed a developer.
We pick experiments by expected revenue impact. We start where traffic is highest and where the metric that moves is revenue per session or booking engine reach, since those tie directly to bookings.
A result earns a wider rollout when it holds up over enough traffic to trust and shows up in booked revenue in the booking engine. Then we roll it to similar properties first, check it holds there, and expand from there.
How did property teams, reservation staff and other frontline colleagues influence the new experience? Were there any operational realities that the digital team initially overlooked, and how are those colleagues feeding guest feedback into ongoing improvements?
Our property teams made the booking experience possible. They pulled together documentation for every booking engine and the promo codes behind each offer, which is what let us put one booking form in front of all 20 properties.
Moving fast meant our first builds missed some edge cases, and the people closest to guests are the ones who spot them. At launch we shared the site with every general manager and our corporate team and asked them to flag anything that looked off.
That loop stays open. Feedback from the front desk and reservations comes back to our content team, and because most updates are instant in the CMS, fixes reach the site quickly.
Hawaii’s destinations and properties have distinct identities. How do you use AI-assisted workflows without flattening those differences into generic hospitality language, and where do local knowledge and human judgment make the greatest difference?
Castle is Hawaiʻi’s only locally owned and operated hotel and vacation rental management company. If our site sounded like everyone else’s, we’d lose the thing that sets us apart.
AI drafts from the facts we give it: each property’s details, its island and neighborhood, and what our guests say about staying there. It doesn’t invent a sense of place. People who know these places then edit for voice, accuracy and cultural correctness, down to Hawaiian place names and diacritical marks.
Local judgment matters most in three places: what we choose to say about a place, how we talk about culture and community, and what different guests need to know. A family visiting from the mainland and a kamaʻāina guest staying on a neighbor island need different things from the same page.
For hotel executives considering a similar approach, when is an AI-assisted custom build the right choice, and when is an established platform or agency still the better option? Looking ahead over the next 12 to 24 months, what would you prioritize next, and what lesson from this project would you most want another operator to take away?
An AI-assisted custom build makes sense when three things are true: someone inside the company can own product decisions, the problem is mostly the front end and content, and you’re willing to own maintenance. If nobody internal can own it, or you need deep reservation or PMS integration, an established platform or agency is still the better call.
Over the next 12 to 24 months we’ll keep building on this foundation: deeper content for every property and island, steady conversion testing, and putting AI to work in more of the business behind the site.
The lesson I’d want another operator to take away: the cost of building has collapsed, and a lot of the industry’s pricing hasn’t caught up. Pick a stack AI can work inside, like Next.js, Sanity and Vercel, with the code in your own GitHub. Then organize your team around fast decisions. The technology is the fast part now.