Offshore Software Developers Staffing

Our Approach with Clients

AppIt Ventures is flexible in how we partner with our clients, from project-based work (on a fixed-bid model) to staffing.  Because each client has individualized needs, AppIt Ventures will collaborate with our clients at the beginning of our relationship to determine the best-fit approach.  In addition to designing a best-fit approach (balancing scope, timeline and budget), AppIt Ventures takes a scrutinizing look at how to reduce risk on each project. AppIt Ventures acknowledges there are inherent risks in custom software development, and we follow a prescriptive process up front to identify risks and make recommendations for mitigation.

 

First Engagements – Validating Fit and Approach

To reduce risk, AppIt Ventures typically begins an engagement in one of two ways:

  1. Initial Engagement.  In this engagement, AppIt Ventures works hand-in-hand with our clients to define detailed requirements, create wireframes (to visualize not only screen layout but overall app flow), conduct valuable research (not only into third-party tool options but also into technology assumptions that can derail a project budget or approach), and provide a detailed project approach (sprint plan, estimate, overall approach).  From this initial engagement, our clients are able to make an informed decision on if they’d prefer to tackle development through a fixed-bid project or through a staffing model. There are pros and cons to both, and we’ve listed out below a typical client profile to help explain the differences in approach.
  2. Code Audit.  Code Audits are a typical first step for projects where code is already written, and AppIt Ventures is taking on work that previous development teams have already completed.  In this engagement, AppIt Ventures takes a close look at existing code, as well as client-provided documentation (typically this involves a list of current defects or unfinished feature sets).  With the code audit, AppIt Ventures will not only provide a detailed report highlighting risk areas in the existing code (which impacts the speed of our development and our ability to deliver on our expectations we set with our clients) as well as a proposed project plan for completing client-requested work.  Following a code audit, it is not typical for a client to move directly into project-based work (project-based work is typically reserved for new feature sets developed from scratch), but rather into either a T&M, Staffing, or Support model. Typically, we see clients leverage just pure T&M, a blend of T&M and Staffing, or a full Support model, and this usually depends on the size, scope and budget of the project.  For example, clients who have active users on their platform will leverage our support model because we have an established process for managing dynamic user feedback and bug reports. Clients who have a limited set of users (sometimes this can be an internal business application rather than customer-facing) or who are still in development or Beta, typically go with a pure staffing model (for those clients who have an internal product manager) or a blend of T&M and staffing (for clients who prefer to have AppIt act as the product manager).  Clients who have a short list of defects or enhancements will typically just go to straight T&M rather than leveraging a staffing model.

 

Project-based work

For clients that have a relatively well-defined idea for a product but are not product owners or would benefit from a blend of expertise that a team of designers, developers, architects, and product owners bring.  This approach offers full service, from design (both creative and architectural) to development to testing (QA) to deployment.

 

  • Tight timeline
  • Still yet to be defined requirements
  • Need for a set of features that falls within a clearly defined budget
  • Need for architectural design
  • Building something from scratch
  • Size (lower complexity or a smaller list of requirements) – projects are a good fit for applications that would take less than 6 months to 1 year of full-time development work
    The need for specialized resources in design or development (in custom apps where we are working on more cutting-edge technology such as AI or complex integrations, a full stack developer may not be the ideal choice).
  • Applications that are on multiple platforms – such as native app development, iOS and Android, plus an admin website.


T&M

For clients that have a specific set of needs that don’t fit well within our defined project-based approach (in other words, an initial engagement would take too much time or add to much rigidity to the project).  This approach offers access to specific, specialized resources for a specific (often shorter) period of time.

 

  • Tight timeline or need to begin immediately
  • Existing code
  • Ill-defined or flexible requirements (sometimes this can be a prototype or minimum viable product, but there is risk here, so we usually spend more time discussing this upfront with our clients before proceeding)
  • If well-defined requirements, these are typically in the form of minor enhancement requests or defect reports.
  • Flexible on budget
  • The need for a blend of specialized resources for shorter periods of time
  • The need for a specialized resource but not on a full-time basis
  • Client may be a product owner and just needs access to specific resources
  • Client may not be a product owner and needs access to specific resources to provide guidance

Staffing

For clients that are comfortable managing their own team of developers, and are clear on their needs and confident in their ability to make architectural decisions and staffing decisions.  These clients prefer total control over their product and process and are comfortable managing the day to day tasks associated with development. This approach offers access to teams of developers or individuals (most often if it’s just an individual, the tech stack is highly focused or the development resource is more of a generalist or full-stack developer) over longer periods of time (typically 6 months to over a year).

 

  • Longer term timeline
  • Client is product owner and can comfortably manage a developer or a team of developers.
  • Can be a new product (would require clearly defined requirements or a sprint plan) or an existing product (would require a large backlog and prioritization of work)
  • Size of product must support a full-time staff for at least 6 months.
  • Product feature set either doesn’t require a specialized skill set or can be developed by full stack developer (unless the project is large enough for a team of specialized developers)


Ongoing support

For clients that have completed active development on a product or an application and have launched or deployed the application for use by consumers (either internal/staff or external/customers).  

  • For existing products, either built by AppIt or by a third party.
  • In support, our clients own/manage Tier 1 support internally (typically), while AppIt shares Tier 2 support with our clients, and AppIt owns Tier 3 support.  
  • Typically, this is a blend between ongoing monitoring (for OS upgrades or required security patches – think of this as an “insurance policy”) and a monthly retainer to cover bugs and desired enhancements.
  • Support agreements are custom-structured based on the overall size of the application in addition to the required level of support.