Software consultants come in many forms, but if you cannot write your own code, finding a developer who meets your needs can be a stressful process that involves much trial and error.
To narrow down good consultancies, we polled experts across the world about the best software development consultants through our TechCrunch Experts program. One of the most-recommended firms we learned about is WolfPack Digital. We caught up with Georgina ‘Gina’ Lupu Florian, CEO of Wolfpack Digital, to talk about her company, how they operate, and the nuances of running a consultancy.
(This interview has been edited for clarity and length.)
TechCrunch: As a developer for hire, how involved do you get when helping clients validate ideas before they bring their apps to market?
Gina Lupu Florian: Our clients often choose us as their sole product and technical partner for their project, which means that we are highly involved in helping them with idea validation. We are here to help them with product discovery and strategy, market analysis, UX/UI design, smoke testing, usability testing, and everything else that is needed to get it right. After the coding phase is completed for any iteration, we support with rolling out the app to beta-testers, and for learning iteratively from the results in a lean way so that an optimal first version reaches the targeted audience at the official launch of the product.
The degree to which we get involved with the idea validation may vary depending on the goals and needs of the project, the founders and/or stakeholders, and the stage at which the project is when we begin our collaboration. Developer-for-hire is a model that has been less common for us in the past few years given our product-oriented approach, although we have ongoing collaborations fitting that model too. We are open to accommodating any setup that works best for our clients and their mobile apps or web platforms.
Can you describe the intake process for new clients? How do you assess their requirements, and what information do you need before you can share timelines and budgets?
The intake process can vary a lot depending on the particularities of each project and collaboration. We typically assess the information provided by our clients and put together a proposal that we refine afterwards with the client as we discover more about the product along the way.
To get to a robust estimated project timeline and budget, we consider user stories, wireframes, and/or a requirements document as the perfect starting point. We can either collect them directly from our clients (if they have them ready after attending incubators, etc.), or we can help with putting them together and join a discovery phase, which typically takes from a few hours to a few days. From the moment we have enough information to prepare a proposal, it usually takes less than a week to deliver it.
Help TechCrunch find the best software consultants for startups.
Provide a recommendation in this quick survey and we’ll share the results with everybody.
What’s a ballpark quote for the average project, and how frequently do you communicate with clients once the work is underway?
In general, questions about quotes are probably amongst the most difficult and yet most common. This is because quotes for web and/or mobile projects can range all the way from a few thousand dollars to millions. It all depends on the scope, and the more clarity there is, the more accurate the estimation. However, when we start a project, we want to make sure that we keep it agile and adapt so as to bring the best product to the market. It’s all about balancing being adaptable while keeping an eye on the budget.
Based on the projects we have taken on recently, the average project size has been in the $100,000 to $200,000 range. Since we are an Agile company, we communicate with clients very often, typically weekly. The communication frequency depends a lot on how hands-on the client wishes to be during the development process — we have projects where we sync with them almost daily, while on others our clients prefer fewer interactions so that they can focus on different parts of their business.
What percentage of your clients are non-technical people who have an idea, but no coding experience? How much of a limitation is that for launching an app?
I would say probably around 50% of our clients are in this situation, either as founders of a startup, or as representatives of companies (product owners in scale-ups, or people in corporate innovation departments, for example). We are here to help with every step of the way, so we don’t see it as a limitation at all.
However, it’s true that having previous experience working with agencies/developers may be useful in terms of familiarity with the software development processes. But absolutely anyone, regardless of their background, can get up to speed quickly, and we are here to support them.
As a consultant, is helping clients avoid scope creep part of your role? If so, how do you help manage their expectations?
Definitely! I think it’s part of our responsibility, and the most important ingredient is clarifying what the priorities are. We encourage ideation, of course, but in the end, we need to focus together on what brings the most value to the product. Besides having clarity with priorities, keeping an eye on a project’s budget and considering it in all decision-making contexts is crucial, as it can be quite eye-opening.
Estimating the work needed for any new feature/change so that informed decisions can be made is also part of the process. Our project managers/product owners also offer their support with relevant questions along the way, and we contribute with suggestions from our team to pragmatically reach the client’s goals with the best results given all the factors involved.
What’s your average timeline for delivering a working app after you’ve signed a contract? What do you need to accomplish before you can share wireframes?
If we are to start a web or mobile app from scratch, respectively, from a set of requirements, and discover it, design it, code it, validate it, etc., it usually takes anywhere from three months to over a year to get to the first version. Most often it’s around six to nine months. It has a lot to do with the complexity of the product, not just from a technical standpoint, but also from a functionalities and product experience perspective to make it attractive to users.
You want your app to have everything it needs so that it’s useful and gets adopted by users by turning it into a better option than whatever it is they are currently using to solve a problem. For a banking app, for example, delivering an app can take longer, because there are many integrations that need to be created, and the fintech market is quite competitive, so you need to have a strong backbone in terms of functionalities in your app. At the same time, the investment brings greater benefits.
Do you also oversee the QA process? Can Wolfpack Digital help clients navigate the approval process for app stores?
Yes. We have an in-house QA team with a special knack for finding hidden issues, and they work closely with our developers and everyone else on the project. We have done App Store submissions hundreds of times, and we have handled a wide palette of scenarios with grace.
We find that approvals work seamlessly 90% of the time, but it may happen that some blockers are encountered (related to terms and conditions, for example), in which case we are ready to take on the communication on behalf of our clients and find a solution, as well as translate to accessible language what the issue and the steps needed are.
Do you provide any marketing services?
This has been part of our plan for a while as we actively receive requests for such services, but we are currently only marketing our own brand and don’t offer marketing execution services to clients. Based on the in-house knowledge that we have on the topic, though, we help our clients with market and audience analysis for their digital products — not just in the beginning, but also as the app scales, to suggest new features based on available data, for example.
So we cover marketing strategy for our clients as part of our product strategy and consultancy service. As a company, we have won awards in global competitions focusing on app concepts and product strategy, and therefore we are particularly passionate about this topic, which includes some strong marketing elements.
Do you work on both hybrid and native apps? What can you tell us about the benefits and drawbacks of each, and when do you encourage clients to go hybrid?
Yes, we work on both native and hybrid technologies for mobile apps, and the choice depends on each project’s type and particularities. There are a few important scenarios where we believe in the power of native iOS and Android. The first one is when scalability and stability are very important right from the beginning — with fintech apps, for example. It’s very likely they will grow in both complexity and user base, so it’s crucial to have a stable app that people can rely on.
Native apps scale better over time, as they use the native frameworks created by Apple and Google, so you don’t have any limits in terms of what can you do. Furthermore, with each new iOS or Android update, the native tech gets updates first, so you can tackle any OS surprises upfront.
Another scenario would be when the app needs to use the hardware capabilities of the phone: Bluetooth, camera, GPS, gyroscope, etc. On the native side, you have direct access to those SDKs, but with hybrid, you need to write your own plugins (in native code), or rely on existing ones from the open-source community. This can become problematic, especially with certain edge-cases (auto-reconnect, change the camera’s parameters, etc).
Hybrid technologies are a good fit when you are looking for quick validation of an idea, or when you’re dealing with a simple mobile app that relies pretty much on the backend. If 90% of the app is just data that you input (forms or questionnaires, for example, for a healthcare app to collect feedback), or display data from the server-side (numbers, charts, or recommendations), then Flutter can be the best option because there aren’t any functionality-related surprises to expect here. Moreover, Flutter allows you to create identical UIs for iOS and Android, if that’s one of the goals, although it’s mostly better to use native elements for each one.
The development time to market is typically shorter if you go for native, because you can move swiftly on two tracks in parallel, while the overall budget, at least initially, is probably higher for native. In the long run, however, hybrid may raise certain challenges that bring the budget of the project to a similar level or even exceed what native offers, depending on what challenges you find on the way, or what new functionality you need to implement.
The maintainability of hybrid is definitely a strong pro, as you have one single code base to maintain. Nonetheless, you need to have devs working on it who are knowledgeable on the chosen hybrid technology as well as on native, in case any plugins are needed, which may make staffing difficult. Overall, there is no right or wrong answer between native and hybrid, and the best choice depends a lot on the particularities of your app.
Have you ever turned down a client? Are there kinds of apps you won’t work on, like e.g, games or dating?
We have turned down clients, and, although our portfolio is quite diverse, it’s important for us that we work on projects that match our values and ethics. We have worked on dating apps, for example, but we’d turn down requests for websites or apps dealing with weapons, illegal drugs, etc.
Games represent a space we have not entered, as the technologies and design capabilities needed to develop games are quite different from our own (including the programming languages used — for example, we use Ruby on Rails, Vue.js, Swift, Kotlin, and Flutter, while Unity is used for games quite commonly). However, many of the apps we develop have a very strong gamification aspect.
Who owns the source code once the project is complete? How is the source code managed?
Typically the client owns the source code, and all the intellectual property rights belong to them, from day one. This is something that is also specified in our service agreement. When it comes to managing the source code, we cover different scenarios, but we usually have a private version-control (Git) repository on our side for each project. The team that works on the project has access to this repository, pushing code regularly while following the Git-flow guidelines.
Once the project is complete, or even at intermediate steps, we transfer the source code to a repository owned by the client. If needed, we assist them with creating a version-control account, then one or more repositories (depending on how many technologies are needed for that project — iOS, Android, backend, etc.), and finally with giving us access to transfer the source code to them.
They will of course also be able to see the commit history and each step along the way. In case any updates are needed, we can either continue to work on our own repositories and transfer the code updates again or push the code updates directly to their repositories. We also have collaborations where we work with the client’s in-house dev team, and therefore the entire team is active on the same repository at all times.
