Recently, my software development team took on a short project to prototype a cross-platform app for tablets. It was meant to find and connect to a Bluetooth Low Energy (BLE) device, configure it, and then read and visualize data from it. To accomplish this, we had just about a month to deliver a prototype in time for a demo to potential investors.
A Short Engagement
The main feature of the device we wanted to interact with was an array of pressure sensors that we could read data from live. We could then visualize these on a 3D model of the device, scaling shapes located where the sensors are to indicate how much pressure they’re reading.
We ended up finding a lot of success in the short time we had. I would attribute that to the makeup of the team, how we worked together, and the tools we picked for the job.
The team was myself as the lead developer, a designer, and our client, who was the founder of their fledgling startup and inventor of the hardware we’d be interfacing with. Since it was just the three of us, we were able to form and try out ideas very quickly. We worked together to envision a 1.0 for the product. Then we trimmed that down into a prototype version with a limited set of features that we felt would demonstrate the value of the product without putting pressure on ourselves to deliver something too big in our short timeframe.
Choosing the Tech Stack
While our designer and the client continued to iterate on and refine our prototype milestone, I could get to work on the app. Needing to target both Android and iOS tablets and being short on time, I opted to use React Native, specifically with Expo.
Another Atomic team has been working on a React Native project, and I was able to lean on a lot of their work and decision-making to get this project off the ground. I used a starter template provided by React Native Reusables, the shadcn/ui library for RN. That meant that, right away, I already had a component library, Tailwind (via Nativewind), and a way to distribute preview builds of the app via Expo’s EAS. Having most of the stack picked out also enabled the design team to iterate quickly, since they could use the same component library to compose screens in Figma.
Specifics
As for specifics on the product we were working for, I knew I’d have to find a library for BLE connectivity, and one for our 3D visualization. For BLE, I landed on react-native-ble-plx. It has the most usage based on activity on their GitHub page. So, I was able to use an example from their repository to get myself moving more quickly with connecting to our device.
For 3D, being a Typescript environment, I went for Three.js, specifically through using expo-three and expo-gl. Because there are so many resources for development with Three, I was able to get rolling relatively quickly, despite lacking experience with the library.
When it came to working with Three, what saved me the most time was the use of Cursor, which provides access to AI agents for assistive coding. This is something I’ve been deeply resistant to. However, I’ll admit it proved invaluable for me while I was starting from scratch. What was important for me while doing this was to be vigilant about not accepting big sweeping changes from the robot. Being able to understand all the output was important. That’s because I knew that, down the line, I’d be responsible for more iteration on this codebase, as well as eventually onboarding other developers who’d need to understand it and work with us.
Planning and Tracking
Returning to planning, all throughout this initial month, we were regularly tracking and planning work in Linear, a lightweight backlog tool, which allowed us to easily categorize tasks and group them into small milestones that would lead us to our first “release” in time for our client’s big demo presentation.
Ultimately, though, there was one major detail to how we worked that was key to the whole process. Our client was able to work in person with us in our office, five days a week. Personally, I’m a fan of being able to work from home as well as in our office, but it’s undeniable to me how valuable this setup was for myself and our team.
Our client is an engineer (albeit not a software engineer). When he started working with us, he had the hardware in a pretty mature state. It was also equipped with a suite of Python scripts built for interaction with the device in all the same ways we would need to replicate in our app. Having him in person and sitting by us regularly cut down all communication time. In turn, that allowed us to validate decisions and iterate on them far quicker than if we had to wait for certain weekly meetings, send emails back and forth, or even just chat on Slack. It’s rare that a project and team will operate this way, and so we recognized how valuable it would be if we could take advantage of it.
Setting Yourself Up for Success Quickly
I’ll admit I was initially worried about this project. A short timeframe to deliver value is always going to be challenging. But having our small team in close proximity to each other, along with our use of a tech stack and tools that allowed us to get up and running quickly, really set us up for success.