Building Tech Products with Paloma Group

Paloma is a digital product studio that’s been credited so far with creating three tech unicorns

Paloma (formerly Dovetail) is a digital product studio based out of Australia and New Zealand. Paloma works with high-growth startups like Afterpay, ChemCloud, and Taper to build unicorn-scale technology products and brands.

We were excited to sit down with two software engineers at Paloma, Saurabh Bhatia and Dan Landers, to find out more about the exciting technology they build and the common challenges they face.

Let’s dive in!

Paloma designed and built the Afterpay consumer platform which is used by more than 5 million people

Railway: Given that you’re both engineers, is it fair to say that Paloma is a technical partner first and foremost? What kind of work does Paloma do?

Saurabh/Dan: Paloma designs and builds world-class digital products (web and mobile) for a diverse range of companies across Australasia and North America. We specialize in building new products for companies, but we also have ample experience augmenting and transforming existing technologies.

We deploy cross-functional product-driven teams across the entire product lifecycle, from day one research and ideation, to scaling for millions of users. Historically, most of our engagements have been B2B SaaS products and we have a strong background in FinTech, but we are industry and tech agnostic with a wide array of clients and ventures in our portfolio.

Paloma built an MVP for the ChemCloud founders in the span of just two months

Railway: Can you walk us through how a new client engages you with a project? Do you draw up a Product Requirements Doc together and then figure out how to architect, schedule, and staff it? What does codevelopment look like?

Saurabh/Dan: Our approach to product building tends to follow a fluid journey of discovery, design, development, and scale. Each of these phases are bespoke depending on the business’ needs. At the start of an engagement, we work closely with founders and clients to assemble the right teams and figure out what we want to build together as our first slice. We call this phase ”Discovery” where we scope requirements from the business, including technical considerations and anything else that will help us determine what we want to build together. Our aim in this stage is always to think about the leanest possible version of a product we can deliver for a particular industry – this bar changes a lot depending on what and where we’re building.

Our main objective is to get something in front of customers for feedback. We don’t see huge value in doing in-depth requirements documents and delivery plans up front as you can never uncover everything you need to know in the early stages of a project. Most of the outputs of these types of documents would change or become irrelevant anyway. Nothing replaces feedback from real life customers.

This is followed by a `Build` phase where we execute on the outputs of our discovery and try to get something in front of customers as fast as possible. We use a platform called Runn, which was built in our venture studio, to schedule and staff each engagement.

Co-development is a scenario we run into quite regularly within Paloma Digital. We work together with our clients as an extension of their existing team. What this means is that we are usually embedded in our client’s work ecosystem – so much so that we essentially work day-to-day as their peers. This means we help them with everything from doing technical work like writing code, to design, product management, and even improving or evolving their internal processes.

Railway: One of the things that seems like a lot of fun is that there is a constant influx of new projects. How do you manage that constant change as engineers?

Saurabh/Dan: There is a continuous flow of new work coming into Paloma across a diverse range of businesses with different technology needs. Our engagement with most of our clients and ventures is longer term. Our team structure on each engagement reflects that and engineers stay on each project for quite some time. This helps us limit context switching and makes us more effective.

We also try to ensure that engagements align well with the skill, interests, and values of our engineers. This makes our job of putting together teams a fun and pleasant experience for everyone including our engineers.

Railway: Saurabh, what can you tell us about something you worked on recently?

Saurabh: ChemCloud is a digital platform that makes it easy to discover, buy, and sell chemicals. For several years, the process of procurement of chemicals, which is a trillion dollar industry in APAC, was stuck in emails.

ChemCloud brought a great deal of transparency into the whole process by laying it out in the form of a digital platform. As the first service of its kind, ChemCloud is  is disrupting the chemicals landscape in a big way, transforming decadesold practices and freeing chemical manufacturers to focus on innovation that truly matters.

Let’s say for example you’re a company that manufactures shampoo and you need to acquire ingredients for your shampoo’s chemical formula. You can create a sourcing request on ChemCloud to solicit quotes from suppliers. You can compare the quotes you’ve received and generate an order if you’re happy with one of them. You can then track and expedite the order all the way through to delivery of the items.

Since we built this venture from scratch, our focus was working in a very lean team environment. This meant we wanted to focus on code and development of the ChemCloud platform rather than worry about managing our servers and thinking about scalability of our infrastructure.

Railway’s platform helped us build the ChemCloud product with both hosting and continuous delivery. It also helps our delivery and quality management through PR Deploys. The flexibility and ability for automation with Railway helps us move fast and continuously deploy to production with confidence. Apart from this, we also love the slick user interface and the Discord support.

Railway: And Dan, how about you? We’d love to hear about your work with Taper.

Dan: Taper is a SaaS platform that helps  clothing businesses ranging from boutique tailors to global retailers offer made-to-measure apparel.

The Taper platform allows retailers to access world-leading manufacturing capability while providing actionable insights and complete visibility of the made-to-measure supply chain from factory to customer.

Taper uses Typescript for both front and back end development. We use Postgres as our primary data store, with Redis for job queues.

Early in 2022, Taper experienced some challenges with our previous hosting provider, but we had heard great things from Saurabh about ChemCloud’s usage of Railway. After a quick product demo, our team saw that it offered a clean UI and looked like a great drop-in replacement. We initially tried Railway with our pre-production environment, where we could immediately see the benefits. It then wasn't long before we migrated our production environment over also.

Railway: How has Railway come into the mix for each of you as a tool? Where have you found it most useful?

Saurabh/Dan: Earlier in 2022, we were having trouble with our hosting provider. Since our process was closely tied to how their platform functioned, our development process slowed down significantly. After doing some workarounds, we started exploring alternatives, and that’s when we started evaluating Railway.

The area where Railway shined compared to the others I evaluated them against was how well it manages pipelines. It has clear support for stage-based environment separation that was flexible enough to work with our existing development process.

Over the last few months, we’ve also migrated our production account to Railway and switched and made our setup more inline with the “Railway way” of doing things.

Another huge benefit was the PR review environments. With Railway's architecture to provision new Postgres and Redis services for each PR environment, we could see great potential in using it as a part of our workflow.To take full advantage of the review environments, we moved our API and frontend codebases into a monorepo using Turborepo. Once our codebase was configured for PR review environments, enabling them was as simple as clicking a button in the Railway UI to allow our team to test code changes in isolation with a copy of our entire tech stack.

Since moving to Railway, we've experienced prompt support whenever necessary as part of the Railway Team plan using our team's dedicated Discord channel, which was a great help when we ran into the occasional build issue.

Railway allows our team to rapidly iterate on products without worrying about servers or infrastructure. Support has been fantastic, and we really appreciate the regular updates and feature releases.

Railway: How can readers learn more about Paloma’s work?

Dan: Check out our website and give us a follow to see what we’re up to.