Call us at 1 (855) 349-2248 
Team Size: 2 people
Schedule: 1 to 2 weeks
If you’re looking to get started with a new project, then this app development service assessment is where you should begin. Learn more about our product consultation process.
The first thing we do in every burgeoning partnership is listen and ask questions. We want to learn as much about your business and your project as possible so we can determine if we’ll make a good fit with each other. If by the end of our app development service assessment we believe we can help, Vice Software will work closely with you to provide product consultation.
Team Size: 2 people
Schedule: 1 to 2 weeks
If you're looking for a team to take over a remodel or existing system, we’ll take a look and give you an honest work assessment.
Our goal is to keep you focused on growing your business while we worry about delivering the tools you need to become a technology leader. Whether you’re a startup or a growing company, we’re available for the long-term offering our app development service to maintain and extend your application’s lifetime value and usefulness.
Team Size: Varies
Schedule: Varies
We'll guide your software idea through discovery, design and engineering with a steady hand.
We believe custom software isn’t just for the big guys. By building only what’s needed, our custom web and mobile app development service delivers affordable applications that will enable your business to scale faster for years to come. We can build exactly what you need from scratch, takeover an existing code base, or even rescue a failed project from other vendors or freelancers.
Getting budgets numbers right is something we know is critical to project success. In fact, it’s one of our core corporate values and areas of focus. After seeing success on many projects of varying sizes, we have developed a recipe for success. We use both Waterfall and Agile on our projects to take advantage of the strengths of each approach. Waterfall – for all of it’s faults – allows for accurate budget and release planning. When it comes to building software efficiently and accurately, we use Agile style processes.
The key to our successful estimations lies in starting with wireframes. We take the time to create a plan and a structure, focusing on UX rather than graphic design and UI. This allows us to more accurately plan out the development of a project and give a more accurate estimation to our customers.
Idiomatic Agile uses historical data to calculate velocity. You start with relative complexity estimates using points and then map points to hours over time measuring your velocity. This works great if you are: 1) disciplined, 2) have a stable team, and 3) can wait until after you’ve started development to determine project deadlines. However, if you are bidding on a project that is five weeks long or needs estimated numbers for a proposal, then you must provide a cost estimate before you start development.
Using Waterfall, we can sit down with project stakeholders and flesh out UX and functionality for the software. By creating the wireframes, we can disambiguate what needs to be built beforehand much better than we can with Agile processes. While the initial estimate will still differ a little from the real cost, we are able to quickly give estimates in ideal hours to our clients. And, because we expect this estimate to differ from the cost, we can account for this known unknown by creating a budget bucket that can only be used for estimation errors.
Usually, using Waterfall to create wireframes at the onset of a project works well, but the UX could very well be the tip of a very large iceberg. If your UX is sitting on top of a distributed architecture like CQRS or represents a view with complex BI manipulations that require more backend muscle, you will need more than wireframes. For the majority of Modern Web projects, we can accurately estimated from wireframes, though.
Deadlines are especially expensive for large projects. We usually recommend against them for most of our clients. However, sometimes they are unavoidable. Our recommendation for larger projects with both budget and deadline sensitivity is to create one more budget bucket for deadline risk.