thoughtbot had the pleasure of partnering with Clara on a recent project. thoughtbot’s deep expertise in Ruby on Rails and Hotwire made us a great match as Clara’s technology partner. We sat down with Ian Gillis, the CTO and Co-founder of Clara to learn more about the company and what led them to choose Hotwire.
What is Clara and what stage is the company in?
Clara is a marketplace for in-home senior care. Imagine your mother or grandmother is getting older and they take a fall. Coming out of the hospital, the case manager suggests that you find them someone to help them get around safely. You would come to Clara and we’d help you find the perfect caregiver, employ them legally, and manage the care on an ongoing basis.
We’re currently a pre-seed stage company going through the YCombinator accelerator.
When it comes to your technology choices, and codebase standards, do you have any guiding principles?
Our motto is “do more with less”. Not because we don’t want to invest in technology, but because we want that investment to be efficient. That means trying to get the most out of every dollar we put towards engineering work while avoiding decisions that are hard to undo.
Especially as an early stage company, we know our direction will (and already has!) changed several times, so this adaptability is incredibly important. For example, it’s relatively easy to “graduate” from basic Heroku hosting to AWS or GCP. It’s harder to go from a big, vendor-specific cloud deployment with lots of Terraform and proprietary services back to a PaaS vendor.
Why did you want to build Clara with Ruby on Rails and Hotwire?
This is my first professional Rails project. I’ve always worked in SPA environments: PHP and React at Facebook; Java and Ember.js at Addepar; Go and React Native at Uber; etc. But when I looked at the surface area of a two-sided marketplace application like Clara, and the limited resources I’d have to build it, I wanted to find a way to minimize context switching and piping data through multiple layers.
I looked at a bunch of different approaches – Go and HTMX, Django, full stack Sveltekit, and more. What clinched the decision for Rails and Hotwire was the direction of Turbo Native. The ability to use a single codebase not only for web frontend and backend, but also for mobile, wasn’t available anywhere else.
Can you speak on your view of the growing trend towards single codebases? Can you touch on why some tech leaders are moving away from React?
I don’t have much data here, but anecdotally there are a couple of trends happening: strong React competitors in the frontend framework space and a renewed interest in backend rendering.
On the frontend framework side, you see competitors like Svelte(kit) and Vue/Nuxt gaining a bit of momentum. There have been some large and somewhat divisive changes in the React ecosystem that have pushed some developers, like myself, to explore the alternatives. For example, the “traditional” SPA approach has been soft deprecated in favor of pushing people to Next.js. This is a more complicated setup maintained largely by a single PaaS vendor, Vercel. Vercel is a great product, but there is some concern about the project over-fitting to their specific system.
The renewed interest in working with a single codebase seems highly correlated with the death of ZIRP. When money was plentiful, it made sense to say, “Hey, if I have this React frontend, Go microservices, and 2 native mobile apps, I can have the highest fidelity experience across every platform.” Now, the conversation is more like, “Well, I know I’m only going to have at most 8-10 engineers through series B. I’ll trade off some fidelity for less overhead.” The great thing in today’s world is that with frameworks like HTMX and Hotwire, we can now build a cross-platform experience that exceeds our users’ expectations without needing to build in three or more different codebases.
In these foundational days for Clara, what are your goals for the product and team? How might Hotwire help you achieve these goals?
We need to be able to try things quickly. That might mean pivoting the entire business or testing a new approach to user onboarding. The faster we can test out a bunch of hypotheses, the more likely we’ll find some that work. Hotwire lets us keep a baseline level of fidelity without sacrificing iteration speed.
Would you recommend your stack to other founding CTOs?
Yes! Our experience with Turbo Native is very limited at this point, so I can’t speak to that piece. But otherwise we’re very happy with the development speed, robust ecosystem, and “batteries-included” nature of Rails and Hotwire.
For founding CTOs in a similar position to you, do you have advice for finding the right development partner?
At this stage, founder time is probably the biggest limiting factor to your success. So the best development partner will have experienced engineers who require only light guidance to be productive. Bonus points if they know more about the tech stack than you do. I’m lucky to have found both with thoughtbot.
If you or anyone you know is in need of in-home care, we recommend you check out Clara, and feel free to follow Clara on Facebook and LinkedIn
thoughtbot is seeing more and more interest in Hotwire and we’re proud to contribute to the community and deliver great outcomes for our clients. We will continue to share learnings and best practices via our blog and have some Hotwire example templates available on GitHub. If you are looking for a reliable user experience that your Ruby on Rails developers can maintain, Hotwire might be a good option to consider. We welcome you to reach out to discuss further.