Types of projects we do
So at this point, you have a working app or MVP, perhaps some customers, and maybe you're at the end of what was, potentially, a very long product development journey. Some of the people who originally started want to move on, there are new investors, new visions and new plans. We can help by providing a solid Tech strategy and implementation to overcome the next phase in your startup journey, by working directly on your main product.
- + Node based development
- + HTML5 Bootstrap based interfaces
- + Firebase apps
- + Cloud hosting and DB
- + iOS, Android
- + Microservices
- + Template-based design
- + Mobile and web based consumer apps
- + Focused on data and function
+ Backend development
- + Cloud operations
- + Product design
- + Startup strategy
Now, normally the problem at large we'll face in a startup with an already validated product is the immediate need to rebuild it. Why? Because, generally that "final" product came to be after a long process of trial and error, and succesive changes, and tests and iterations, that have resulted in internal issues, spaghetti code, and design problems. These things occur naturally during the previous experimental phase, but now, it's time to build a more stable product that incorporates in a solid design what the team has already learnt.
In addition to documenting the current set of user functionality to be enabled by the app, we need to concern ourselves with new things that perhaps weren't so relevant when starting out, like security and scaling. Generally, the more popular the app, the more we need to worry about these two things.
To maximize our gains in these areas, and minimize our work and error potential, we favor using as many ready-made and tested components or stacks or backends, as is reasonably possible, instead of building out everything from scratch, except in the case where the main product we're talking about has such unique characteristics that it's just not feasible to use pre-made parts to assemble it.
The incremental approach
In short, this means to break up a large goal into sub-component goals, meaningful objectives by themselves, that can be completed with less effort and allow us a pause to assess the current situation before proceeding further. Like chapters of a book, each stage should convey a sense of completion by itself, even if it is part of a larger story.
In particular, we want to avoid the trap of building too much, without properly vetting it by real-life use. Often, there's a disparity between what we humans think it's best, and what reality shows us, so the strategy here is to take smaller steps and immediately send the results for real world validation, thus correcting course as needed with the findings.
To be clear, this is not about building independent parts of the overall solution, but rather, building complete mini-solutions while heading to the final goal.
The rollout phase
So for each one of our previously achieved development stages, we will consider, depending on the app, the client, the users and the overall strategic situation, to get the app into the hands of its real, final users. The important thing here, is that even if we are 100% confident on the quality and suitability of the job we'd done together with the client, we still need an incremental approach to rollout.
The rationale behind this is to limit our risk exposure by avoiding the possiblity of letting an undetected problem pass, and reach 100% of our users, which will then be affected by whatever it is. So instead of assuming us to be fool-proof, we'll instead assume that there will be issues, and we'll let into the app only a handful of users at first, then carefully observe and monitor the situation, before allowing a larger number of users in, and so on.
You should know that all of our development work comes with a 3 month warranty against programming defects, that they will get corrected at no extra cost, once reported. A "defect" is a deviation from the functionality stated in the SRS or a badly performing one, technically speaking. For example, "The app will return the number of customers active within the year specified in the search field" but in actuality, you discover, after 1 month, that the search in question returns ALL customers, regardless of the year that they were active. So, this is a "programming defect" and you can report it for correction.
The warranty DOES NOT cover changes in external circumstances, new business goals on the part of the client, or issues outside of our control. For all of those cases, as well as the situation when a problem is discovered after a lot of time has passed, we will remain available to assist you by any of our support options available at the time.
For now, the important take away for you, as our client, is that we'll remain committed to deliver you working solutions, and we'll stay reachable afterwards to help you with whatever new developments might arise in the future.
Evaluate, to plan for next steps
We firmly believe that the path to success is one of continuous improvement, and in that sense, what worked yesterday, might not be the best fit for tomorrow, therefore, actionable knowledge is critical to future performance.
Once we're satisfied with our current results, it'll be time to think about implementing monitoring strategies to track key metrics related to the original goals of the project. In this way, we will be better able to advice you on the path to take with a follow-up, or even a completely new project; either way, supported by evidence as much as possible, instead of only intuition.
Focus on key metrics
There are many things to track, but the idea here is to engage resources to track first the things that are likely to have the biggest impact on our goals.
We will assist you not only in obtaining relevant numbers but in deriving well thought and evidence-based, documented conclusions from them, to enable proper and justified future decisions.