Earlier this year, I was introduced to a potential client. They had the perfect project for The Gnar, developing and launching an iOS app, but I didn’t think we were the right partner for the job.
Three months later, they just launched their new app…that we built.
Here’s how it happened:
I had an initial call with the client stakeholders to discuss what they were looking for. These are the details:
- They already had designs and a Figma prototype for the MVP.
- The scope included building the front-end, back-end, and a web admin view.
- They were expecting to launch an MVP in 1-2 months with one full stack developer.
- Discussions with other vendors had already resulted in a wide range of proposals ranging from $100/hr - $175/hr and 275 hours - 1600 hours.
Within a few hours I responded with a quick reaction. I didn’t think we were going to meet their timeline and budget needs, and I didn’t want to waste their time reviewing an SOW that wouldn’t work for them. My gut, despite knowing we could knock this out of the park for them, said that this project was going off-shore and they would get sticker shock at our proposal.
I was concerned about the timeline and staffing level, and I gave my specific rationale (the volume of integrations and number of applications needed - API, mobile app, admin dashboard - were big drivers). To do this work the right way, I suggested two engineers for 10-15 weeks. That would allow us to split the front-end and back-end features between devs or double-down on each to speed up the timeframe. I also offered to reduce our rate by ~10% to get closer to their budget - I knew this was work we could do really well and that budget was a concern.
What happened next is why I knew this would be a fantastic partnership.
Here’s the key line in the client’s response: “I'd love to explore ways to reduce the cost if that means a longer time to market, reducing features for the MVP, etc.”
At The Gnar, we’re problem solvers first and technologists second. If the best solution for your product had nothing to do with code, we would suggest it. We love it when our clients are similarly flexible and want to build products the right way with a focus on outcomes, not outputs.
In terms of project scoping, we were all downhill from there. I had a draft SOW in their inbox the next day and a final version was signed by the end of the following week.
That’s where the fun began.
Due to the collaborative nature of the scoping process, we were primed to jump into this project quickly and hit the ground running. We never use fractional resources on projects, so after the project kickoff with the client they were 100% dedicated to executing on the project requirements. On the client side, our in-depth discussions gave them the ability to set up all necessary accounts and admin requirements well in advance so we weren’t spending the first week waiting for those.
Despite some of those other vendor estimates, turning an app from nothing to something in three months is a tall task. However, it’s a challenge Gnar developers are used to taking on and know how to approach.
As I mentioned earlier, integrations were a big part of this work. And although integrations take time, integrating an existing service is almost always going to be faster (and probably better) than custom building a specific feature. Based on that experience, our developers leveraged solutions like Twilio Verify for authentication and Stream Chat for… chat to cut down the timeline significantly.
A collaborative scoping effort led to crystal clear requirements which gave our dedicated developers the ability to map out their work and execute a plan with tremendous speed. It also led to a better product. We have founder oversight on every project at The Gnar. Which means we have a business owner/technologist thinking about the big picture and making sure we’re not getting bogged down in details that don’t actually matter - and we’re not building things that won't scale for business purposes.
That came in handy here.
The week before launch, the client told us that they only wanted the app available in one city to start. Easy enough, but the devil is in the details.
It would have been easy to build out that functionality as a one-city solution, making it very difficult to expand over time (or requiring the same development team to step back in). But, given our team structure, it was natural for us to think about the solution as a business problem. Did the client plan on expanding over time? Will they eventually hire their own full-time team? When we answered those questions, the necessary solution became apparent. We updated the app so it will only be available in one location for now, but it can be easily rolled out to more cities over time. Where others may have cut corners scrambling to launch the product, our thoughtful approach led to a better result in the same amount of time.
So with that - three months and two developers later - we launched the app.
___
We joke that working with the Gnar is simple and easy, but the work we do is simple and hard. That’s very true here. We’re focused on putting the customer first and being flexible to accommodate your needs. But we’re equally focused on doing the hard work to make sure the product is being built the right way, without overly complicated solutions.
Also, if you liked this article please subscribe to our newsletter