Mobile App Design & Development

I have an idea for a mobile app and the business case feels strong, but I have heard too many stories of apps that cost a fortune and went nowhere. How do I figure out if mine is actually worth building before I commit the money?

This is the right question to ask before any code is written, and it is the question most app projects skip past too quickly. The instinct, once you have an idea you believe in, is to start asking how to build it, who to hire, and what it will cost. These are all valid questions, but they are the wrong ones to lead with. The first question is whether the app should exist at all in the form you are imagining, and that question deserves serious work before anything else gets committed.

The reason the failure rate is so high in mobile apps is not that the technology is unreliable or that the engineering is too hard. The technology works. The engineering, done by competent people, produces working products. The failure rate is high because most apps are built on top of a strategic premise that does not hold up, and no amount of design or engineering can save an app that should not have existed in the first place. The work that determines success or failure is the work that happens before the build, and most projects underinvest in it dramatically.

A few specific questions, asked honestly, will tell you most of what you need to know about whether your idea is worth committing to.

The first is what specific problem the app is solving for whom. The honest version of this question is harder than it sounds. Many app ideas are framed as solutions in search of a problem. They describe what the app will do without being able to articulate the specific pain point in someone’s life that the app removes. If the answer to “what problem does this solve” is general or aspirational, the idea probably needs more work before it should be built. If the answer is specific, with a named user group and a concrete situation that the app changes, the idea has a real foundation to build on.

The second is how the user is solving this problem today. Every problem worth solving with an app is currently being solved some other way. People are using a website. They are using a competing app. They are doing the work manually. They are not doing it at all. Understanding the current state matters because it tells you what your app actually has to beat. If users are currently using a competitor that works reasonably well, your app needs to be meaningfully better, not just different. If they are using a workaround they hate, your app needs to be just barely good enough to be preferable to the workaround. If they are not solving the problem at all, you may be facing the hardest situation, which is convincing them they should start. Each of these scenarios produces a different cost of acquisition, a different design priority, and a different bar for what success means. Knowing which one you are in before you build is critical to scoping the project properly.

The third is whether the problem is acute enough that users will actually adopt a new app to solve it. This is where many app ideas quietly fail. The friction of installing a new app, learning it, granting it permissions, and integrating it into the user’s life is significant. Users will absorb that friction for problems they really care about. They will not absorb it for problems that are minor inconveniences, even if the solution is elegant. The honest test is whether the problem is severe enough, frequent enough, or central enough to the user’s day that they would change their behavior to use your app. If the answer is no, the app may still be a good idea, but it will require significantly more marketing investment to drive adoption than the build itself, and that math has to be considered alongside the product.

The fourth is whether mobile is actually the right form factor. Many app ideas would be better served as websites, browser extensions, or features inside other products. The question to ask is what mobile specifically does for this idea that other channels do not. If the answer is access to camera, GPS, push notifications, native performance, or offline functionality, mobile is genuinely the right call. If the answer is general convenience or a vague sense that everything should be an app, the case is weaker. Many businesses build apps because their team or their competitors have apps, and the strategic premise is never examined. The test of whether mobile is the right channel is whether the app actually requires the things mobile uniquely provides, or whether a well-designed mobile-responsive website would do the same job at a fraction of the cost and complexity.

The fifth is what the unit economics look like. Building the app is one cost. Acquiring users is usually a larger one, and most app projects underweight this in the planning. App store optimization, advertising, partnerships, organic content, the cost of getting your app into the hands of users is real and recurring. The math on the project has to include not just the build but the ongoing acquisition cost, balanced against what each user is worth to the business. If the customer lifetime value is high enough to support the cost of acquisition through paid channels, the project is fundable. If the math is marginal, the project depends on organic distribution, which is harder to engineer than most operators realize. Doing this analysis before the build, even roughly, tells you whether you are looking at a project that can pay back or one that will struggle even if the product is good.

The sixth is whether you have the team and operational capacity to maintain the app after launch. The honest reality of mobile is that the launch is the start of the work, not the end. Apple and Google release platform updates that require app updates. Users report bugs that have to be fixed. Features that turn out to be more important than expected need to be expanded. Features that nobody uses need to be removed. The app needs marketing, customer support, and ongoing product investment for years after launch. If your business has the team and the budget to sustain this, the project is viable. If not, the app will degrade quickly after launch, and the initial investment will be lost to the slow decay that happens to apps without sustained attention.

When these six questions are answered honestly, the picture of whether the app is worth building becomes much clearer. Some ideas pass all six. Those are the ones that justify the investment. Some ideas pass most of them but fail on one. Those are usually fixable by scoping the project differently, addressing the weak point before the build, or finding a different way to solve the problem that does not require the full investment. Some ideas fail several of the questions. Those are the ones where the honest answer is that the app should not be built, or at least not in the form currently imagined.

The conversation we have with clients in this position is exactly this conversation. We are not trying to win the build at any cost. We are trying to figure out whether the build should happen, and if so, what form it should take. Some of the engagements we are proudest of are the ones where we advised the client not to build the app they came to us for, or to build something significantly different and smaller than what they originally described. The honest counsel up front saves clients significantly more money than they would have spent on the wrong build, and it produces the kind of trust that turns into long relationships.

If you have an idea you believe in, the right next step is not to start scoping a build. It is to do the strategic work that tells you whether the build is worth doing. We help clients do that work, and the cost of doing it properly is a small fraction of the cost of building the wrong app.

---

A few customers have asked for an app. How do I tell if that is real demand worth investing in, or just a handful of requests I should not build around?

This is one of the most common ways app projects get started, and it is also one of the most expensive ways to make a wrong decision. A handful of customer requests is a real signal, but it is not the same signal as real demand, and treating the two as equivalent is how businesses end up with apps that cost a fortune and never produce the engagement that justified the build.

The reason this happens is that customers asking for an app are usually expressing something specific to them, in the moment, that may or may not represent a broader pattern. Their request is genuine. They would probably use the app if you built it. But the question that matters for the business is not whether those particular customers would use it. It is whether enough customers would use it, often enough, that the investment in building and maintaining the app produces return. A few requests cannot answer that question, and acting on them as if they could is one of the more common ways app investments go wrong.

The work to figure out whether the requests represent real demand is concrete, and it can be done without committing to a build.

The first thing to do is examine the requests themselves carefully. What specifically are these customers asking the app to do? If three customers asked for an app and all three described different use cases, the requests are not telling you the same thing. They are telling you that the idea of an app is appealing to several customers, but they each have a different idea of what it would do. That is a much weaker signal than three customers describing the same use case in similar words, which would suggest a real common need worth investigating further. The pattern in the requests matters more than the count of requests.

The second thing is to talk to more customers, deliberately. Not just the ones who happened to ask. The customers who did not ask are equally important to understand, because they are the larger group, and what they would use is what determines whether the app makes sense for the business as a whole. Structured customer conversations, where you describe the potential app and ask honest questions about whether they would use it, what they would use it for, and how often, produce far better signal than a handful of unsolicited requests. The conversations have to be designed carefully, because customers will often politely say they would use something they would not actually use, but with the right framing the answers become reliable enough to act on.

The third thing is to look at what the requesting customers are actually doing today. If they are currently using your website or product on mobile, look at the patterns. Are they completing the same tasks they would do in an app? Are they running into specific friction that an app would remove? Are they coming back frequently enough that an app would meaningfully improve the experience compared to the web? If the answer to these questions is yes, the requests are aligned with real usage patterns and the demand may be real. If the answer is no, the requests are aspirational, and an app might not actually change the behavior of the customers asking for it.

The fourth thing is to consider whether the requests are about an app specifically or about better mobile experience generally. Many customers ask for apps when what they actually want is faster, more responsive, more usable mobile interactions with your business. Sometimes the right answer to those requests is a significantly improved mobile website, not a native app. The investment in mobile web is usually smaller, the user friction is lower because nothing needs to be installed, and the result often satisfies the underlying need that produced the requests in the first place. The honest question to ask is whether your customers want an app, or whether they want their mobile experience to feel better, and an improved web experience might be the answer.

The fifth thing is to do the rough math on what would justify the investment. The cost of building the app is one number. The cost of maintaining it for the next several years is another. Acquiring users beyond the few who asked is a third. These numbers add up to something significant, and the business has to be able to project enough engagement and value from the app to justify them. If the requesting customers represent a small percentage of your overall base, and the app would only be useful to a similar small percentage, the math probably does not work. If the requesting customers are the leading edge of a much broader pattern that you can identify in your data, the math may work, and the investment is worth more serious consideration.

The sixth thing is to look at what your competitors and adjacent businesses are doing, but to look critically rather than reactively. The fact that competitors have apps does not mean you need one. Many competitor apps were built on the same weak signal you are now experiencing, and they may be quietly producing very little engagement despite being live. The right question is not whether they have an app, but whether their app is actually working for their business, which usually requires some investigation beyond just checking the app store. Adjacent businesses that have similar customer bases and have made the app decision can be more useful sources of information, particularly if you can talk to them about what the app has and has not produced. The market signal is real, but the market is also full of apps that should not exist, and following the herd is one of the more common failure modes.

When this work is done properly, the picture of whether the requests represent real demand becomes much clearer. Sometimes the answer is yes, and the investment is worth making. Sometimes the answer is partially, and the right move is to address the underlying need with something smaller than a full app build. Sometimes the answer is no, and the right move is to acknowledge that a few requests do not constitute real demand and to redirect the investment somewhere with stronger signal.

The conversation we have with clients in this position is exactly this conversation. We do the structured work to figure out what the requests actually mean, what the broader demand picture looks like, and whether the investment is justified. The output is a clear recommendation grounded in real evidence rather than in instinct. We have advised clients to build the app when the signal was real, to skip the app when the signal was weak, and to invest in better mobile web when the underlying need did not actually require an app. The honest answer depends on the evidence, and the work to gather it is dramatically less expensive than the cost of building the wrong app.

The most expensive mistake in mobile apps is not building badly. It is building something that should not have been built. The work to avoid that mistake is the work to do before any code is written, and it starts with taking customer requests seriously without treating them as conclusions. They are evidence to investigate, not decisions to act on, and the difference between those two postures is often the difference between an app that produces real value and one that becomes another expensive cautionary tale.

---

Should we build a custom app, or can we validate the idea with off-the-shelf tools first before committing to a real build?

This is one of the most useful strategic questions you can ask, and the answer is almost always yes, you should validate first. The instinct to build the full custom app from the start is understandable, especially when the idea feels strong and the urgency is real. The trap is that committing to a full build before the core assumptions have been tested is one of the most reliable ways to spend significantly more money than you needed to, on a product that may not be the right one even when the engineering is done well.

The validation conversation has changed dramatically in the last few years. The no-code and low-code landscape, combined with AI-assisted development, has produced an environment where you can stand up a working version of many app ideas in a fraction of the time and cost it would have taken even three years ago. The validation does not require pretending to test something. It requires putting a real, functional version of the core experience in front of real users and learning whether it actually changes their behavior. Done well, this is one of the highest-leverage investments a business can make before committing to a custom build.

The first thing to understand is what validation is actually trying to prove. Most operators frame validation as proving whether the app is a good idea. The real question is more specific. Validation has to test the assumptions that, if wrong, would make the full custom build a mistake. Those assumptions are usually a small number of specific claims about user behavior, business model, and demand. Will users actually adopt the app and use it the way you expect. Will they keep coming back. Will the business model work in practice the way it works on a spreadsheet. Will the user acquisition costs be in a range that the unit economics can support. Each of these is testable, often with surprisingly modest investment, and each of them is the kind of thing that should be known before a six- or seven-figure build begins.

The second thing is to choose the right validation approach for the specific question. Different assumptions require different tests. If the core question is whether users will adopt the app at all, a no-code MVP delivered to a small initial audience can produce a clear signal within weeks. If the core question is whether users will keep using it, the validation needs to run long enough to measure real retention, which usually means months rather than weeks. If the core question is whether the business model works, the validation has to include the commercial transactions the model depends on, not just the user experience. The validation approach has to match the question, and most validation efforts fail because they tested the easier question rather than the one that mattered.

The third thing is to know what tools are appropriate for which validations. The current landscape includes several distinct categories. No-code app builders like Bubble, Adalo, and Glide can produce functional mobile experiences quickly, with real backends, real authentication, and real interactions. They have limits, but the limits usually do not matter at the validation stage. Progressive web apps, which behave like apps but run in the browser, can deliver a mobile-first experience without requiring app store installs, and they remove one of the biggest sources of friction during early validation. Existing platforms with mobile presence, like Shopify, Webflow, or Notion, can sometimes host validation experiences that would take significant custom work to build from scratch. For more sophisticated needs, AI-assisted development tools have made it possible to produce functional custom code at a fraction of the time it would have taken a year ago, lowering the cost of validation that requires real custom work.

The fourth thing is to be honest about what validation cannot prove. Some questions can only be answered at full scale. The performance characteristics of an app under heavy load. The product polish that distinguishes a successful app from a competent one. The integrations with backend systems that have to work reliably for business operations. These are questions the custom build has to answer, and trying to validate them with no-code tools usually produces false signal. The right framing is that validation answers the strategic questions, and the custom build answers the execution questions. Each has its place, and skipping either one is a mistake.

The fifth thing is to commit to acting on what the validation shows. The most expensive validation is one that produces clear evidence the idea needs to change, and then gets ignored because the team had already mentally committed to the build. The validation has to be approached genuinely, with the willingness to either move forward, pivot, or stop based on what the evidence reveals. Companies that do not have this discipline often find that the validation phase becomes theater, a checkbox they completed before doing what they had already decided to do. The validation should be a real decision point, not a formality.

When the validation is done properly, several things happen. The strategic questions get answered with real evidence. The custom build, if it proceeds, is informed by what was learned and scoped against the actual user behavior rather than the assumed user behavior. The cost of the eventual build is often lower because the team is building against a clearer specification. The chance of the build succeeding is significantly higher because the underlying assumptions have been tested. And in some cases, the validation reveals that the full custom build is not necessary at all. Some businesses end up running on a sophisticated no-code or hybrid stack indefinitely, because the validation showed that the limits of those tools were not actually constraining the business, and the cost of a custom build would not have produced enough additional value to justify it.

The conversation we have with clients in this position is exactly this conversation. Sometimes the right answer is to validate carefully before committing to anything. Sometimes the right answer is to skip validation because the assumptions are already well-understood from existing data or business context, and the build should proceed directly. Sometimes the right answer is a hybrid approach, where validation runs in parallel with the early phases of the custom build, with the build scope adjusting as the validation produces evidence. The right path depends on the specifics of the situation, and the work we do is to help you figure out which one fits your business.

The most expensive build is the one that did not need to happen. The second most expensive is the one that happened in the wrong form because the assumptions were never tested. Validation, done well, protects against both of these, and it is one of the highest-return investments a business can make in the mobile space right now. We help clients design and run the right validation, draw the right conclusions from it, and make confident decisions about what to build next based on real evidence rather than on hope.

---

I could hire a freelancer, use a no-code platform, or work with a real agency. What is the actual difference, and when does each one make sense?

This is a good question to ask honestly, and the answer is not always the agency, despite what an agency is incentivized to tell you. Each of these three paths has a place, and the cost of choosing the wrong one is usually higher than the cost of the path itself. Understanding when each makes sense will save you significantly more money than any specific decision about which one to use.

The freelancer path makes sense in a specific set of conditions. You have a clear, well-scoped piece of work that does not require strategic input. You can articulate exactly what needs to be built, with the precision of someone who has scoped this kind of work before. The build is small enough that one person can deliver it without the project becoming a coordination problem. You have someone internally who can manage the freelancer, review their work technically, and step in when problems surface. You have the time and the patience to find a freelancer who is actually good, which is genuinely difficult, because the variance in freelance quality is enormous and the signals that distinguish good from bad are not always obvious to non-technical buyers. When all of these conditions are met, a freelancer can be an excellent and cost-effective choice for the right project.

The freelancer path becomes risky when any of these conditions are missing. If you do not know exactly what needs to be built, you need a partner who will figure that out with you, and freelancers are usually not in a position to do that work seriously. If the project is large or complex, the coordination burden falls on you, and the project becomes harder to manage as it grows. If you do not have technical depth internally, you cannot evaluate whether the freelancer is doing the work well or producing code that will become a liability later. If the work needs to integrate carefully with other systems, span design and engineering and product strategy, or evolve over time as the business changes, the freelancer model usually breaks down because no single person carries the breadth of skills the project actually needs. The cost savings of a freelancer are real when the conditions fit, and they evaporate quickly when the conditions do not.

The no-code platform path is where the landscape has shifted most dramatically in the last few years. The tools are genuinely capable now, and the case for using them has become much stronger for certain situations. A no-code platform makes sense when the app’s value comes from the workflow it enables rather than from any unique technical capability. When the data structures are reasonably standard. When the integrations needed are with tools the no-code platform already supports. When the user base is moderate enough that the performance characteristics of the platform are not a constraint. When you have someone internally who can build and maintain the implementation, which is a skill in its own right but a smaller one than full custom development. Under these conditions, a no-code build can produce a working app in weeks instead of months, at a fraction of the cost of a custom build, and the app can be maintained and evolved by the business without dependence on external developers.

The no-code path runs into limits when the requirements outgrow what the platforms can support. Highly custom user experiences that need to look and feel a specific way. Performance-sensitive applications where the overhead of the no-code platform becomes noticeable to users. Integrations with systems the platform does not support, which often requires building custom middleware that erodes the simplicity that made no-code attractive in the first place. Apps that need to operate at significant scale, where the pricing of the no-code platform becomes meaningful and the architectural decisions of the platform become limits you cannot work around. Apps that are core to the business strategy and need the kind of differentiation that comes from owning the underlying technology. When you cross any of these thresholds, no-code stops being the right answer, and the move to custom becomes necessary even if it was not initially required.

The real agency path makes sense for the projects where the other two paths break down. When the project is large enough that it requires the coordinated work of designers, developers, and product strategists, with the depth in each discipline that a freelancer cannot provide. When the work requires strategic input on what to build, not just execution against a brief, because the business does not yet know exactly what the right product looks like. When the app needs to integrate with other systems in your business in ways that require real engineering judgment. When the project is going to evolve over the years following launch, and you want a partner you can rely on for the ongoing work rather than starting over each time. When the app is central enough to the business that you cannot afford the variance of relying on a single freelancer or the limits of a no-code platform. When you need someone to be accountable for the success of the project in a way that goes beyond delivering against a specification.

The right agency does more than just write code. They bring product thinking to the work, push back on assumptions that should be tested before being built into the product, contribute to the strategy underneath the app rather than just executing the strategy you arrive with, and treat the engagement as a partnership that produces a system the business can grow with rather than a deliverable to be handed off. The variance among agencies is also significant, and choosing a real agency at the higher end of this work is meaningfully different from choosing a shop that calls itself an agency but operates as a freelance collective with a logo. The signals that distinguish the two are usually visible early in the conversation. Real agencies engage seriously with your business before they engage with the build. They are willing to tell you when something you described is not the right answer. They show up with a perspective rather than waiting for instructions. The agencies that operate as order-takers, executing specs without engaging with the underlying strategy, often produce results closer to the freelance experience than to what you would expect from a strategic partner.

The honest framework for choosing is this. If the work is simple, well-defined, and small, and you have internal capacity to manage it, a freelancer is often the right answer. If the workflow value can be delivered through what no-code platforms support, the build is moderate in complexity, and the business can maintain it, no-code is often the right answer. If the project is strategic, large, or evolving, and the success depends on the kind of cross-disciplinary work that requires a real team, working with the right agency is usually the right answer. The mistake most operators make is choosing one of these paths because of price or because of familiarity, without actually mapping their situation against the conditions that make each one appropriate.

What we tell clients in this position is that we are not the right answer for every project, and we will tell you when we are not. We have advised clients to use a freelancer when the scope made that the right call. We have advised clients to build on a no-code platform when the requirements fit and the cost savings were significant. The conversations we have are not designed to win the work at any cost. They are designed to figure out what the right path is for your situation, and to be the right partner for the projects where a real agency is what is actually needed. The honest counsel up front produces better outcomes than the alternative, and it is the kind of relationship most of our long-term clients value most.

---

Our Approach

The mobile app industry has a problem, and it is worth naming directly before talking about how we work differently. Most app projects fail. The failure rate varies depending on how you measure it, but the consistent reality is that a significant majority of apps either never launch, launch and fail to gain traction, or gain traction briefly and then quietly decay. The cost of these failures is significant, both in the direct investment lost and in the opportunity cost of the time, attention, and team capacity that went into the wrong project. Yet the industry keeps producing the same outcomes, and the pattern keeps repeating, because the model most agencies use is structurally incapable of producing different results.

The standard model goes like this. The client comes to the agency with an idea. The agency engages around what to build. The build proceeds. The app ships. The relationship ends, or shifts to a maintenance arrangement where the agency responds when things break. Throughout this process, the strategic questions that actually determine whether the app will succeed are rarely engaged with seriously. The agency does not have a strong incentive to challenge the build, because challenging the build risks losing the work. The client does not have the depth in mobile to challenge their own assumptions, because if they did, they would not need the agency. Both parties move toward the build because that is what each of them is set up to do, and the harder strategic work that would have determined whether the app should be built at all gets skipped past.

We do not work this way, and the reasons are worth understanding before any conversation about a specific project begins.

The first thing we do that most agencies do not is push back on the build itself when it is the right thing to do. We have advised clients to not build apps that they came to us wanting to build. We have advised them to build something significantly different from what they originally described. We have advised them to validate the idea with no-code tools or improved mobile web experiences before committing to a custom build, and in some cases the validation has revealed that the full app was not actually necessary, saving the client significantly more money than they would have spent on the build we did not win. This posture is not in our short-term commercial interest. It is in our long-term interest, because the clients we have advised honestly have stayed with us for years across multiple projects, and the trust that comes from being honest at the start has produced more sustainable business than winning every build at any cost would have.

The second thing we do differently is engage with the strategic questions seriously before the build. The work that determines whether an app succeeds is not the work of writing code. It is the work of understanding who the users actually are, what problem the app is solving for them, how the app fits into the broader business model, what the unit economics need to look like to justify the investment, and what success looks like in measurable terms. These questions are answered before we start designing or building, and the answers shape everything that follows. The build that comes after this work is grounded in a real understanding of what is being built and why, which is the foundation that distinguishes apps that succeed from apps that look good in the demo and fail in the market.

The third thing we do differently is bring product thinking to the work rather than just engineering and design. Most apps that fail technically were fine. The engineering worked. The design was reasonable. The failure was upstream of execution, in the choices about what to build and how it would fit into users’ lives. Product thinking is the discipline that catches these failures before they get built into the product, by interrogating the assumptions about user behavior, business model, and competitive context that the build is implicitly relying on. The product thinking is woven into every phase of the work, not concentrated in a single early phase, because the strategic questions keep surfacing as the build progresses and answering them well as they arise is what separates a project that stays on track from one that drifts.

The fourth thing we do differently is treat design with the seriousness it deserves at every layer. Most app failures that look like execution problems are actually design problems. The user experience did not feel right. The first interaction did not establish trust. The information architecture did not match how users think about the problem. The visual design did not signal the quality the user expected. These failures look superficial, but they are the difference between an app that gets used and an app that gets deleted, and they require the kind of design depth that most agencies talk about but few actually deliver. The design work we do is informed by extensive experience with what works on mobile specifically, with care for the details that compound into an experience users actually return to.

The fifth thing we do differently is engineer for the long term, not just the launch. Apps that succeed are apps that get maintained, extended, and improved over years. The technical decisions made at the start of the build determine whether the app can be evolved cleanly or whether it becomes a liability the business has to work around. We make those decisions with the assumption that the app will be alive and changing for the long term, with the architectural discipline that supports that, and with the documentation and code quality that allows another team to pick up the work if necessary. The result is an app that does not just launch successfully but stays healthy as the business grows and the platforms evolve around it.

The sixth thing we do differently is stay engaged after launch. The launch is the start of the real work, not the end. Apps that succeed are apps where someone is watching what is happening, refining the experience based on real user behavior, fixing the issues that surface in production, extending the functionality as the business identifies new needs, and keeping the technical foundation current as the platforms continue to evolve. The agencies that disappear after launch produce apps that decay quickly. The relationships that compound are the ones where the partner stays involved in the ongoing work, and we structure our engagements to support that. Some clients want a defined project with a clean handoff, and we can deliver that with documentation thorough enough that another team can take over. Most clients, once they see what the relationship can be, want us continuing to work with them past the launch. The compounding value of the work happens in the months and years that follow, and the partnership is designed to capture that value.

The reason we work this way is that we have watched too many businesses spend significant money on apps that failed, and we are not willing to be the agency that produces those outcomes. The work we do is designed to produce a different result. Apps that should not have been built do not get built. Apps that should be built are built well, with the strategic depth, design discipline, and engineering quality the work requires. The apps that ship are positioned to succeed in the market, not just to launch impressively. And the partnership continues past launch in a way that protects the investment for the long term.

If you have an idea you are excited about, or customers asking for an app, or a sense that mobile should be a bigger part of your strategy, the conversation we want to have is not about what we will build. It is about what is actually going on, what your customers really need, whether mobile is the right answer, and what form the work should take if it is. That conversation has produced some of our best engagements, and some of our most valuable advice has been to not proceed with the build that the client originally came to us for. The honest work at the start is what makes the work that follows worth doing, and it is the standard we hold ourselves to on every project.