Thoughts > Minimize Risk

Our Methodology for Successful Application Development Projects

When launching and managing a complex application at scale, bringing the full project plan into focus early in the process is essential. Every new development project should start with both clear goals and a clear plan for how it will be operationalized.

It starts with a well-structured discovery process. During this phase, it’s essential to build a plan and process for managing launch and post-launch operations. The discovery process should consider both technical and organizational resources and expected load and growth over time. As the application is built, the team should keep the operational plan in mind and regularly revisit it as the project matures.

Project Management

Strong project management is the linchpin of every successful project. It’s the interface layer between a development partner’s internal teams and the project stakeholders. They build the roadmap, keep the project on schedule, handle new requests and bug reports, manage quality assurance, and supervise new releases.

All projects change once development begins. It’s essential for development teams to be responsive as business needs evolve. Following an agile methodology makes adapting to change faster and easier. Bringing project stakeholders into the project management workflow helps with this since it gives them a clear sense of the scope, the current sprint, and the roadmap. As new requirements arise, project managers can work with the development and operations teams to build them into the schedule while balancing costs, time, and system dependencies.

Project managers should also be the first users of the applications being built. Effective project managers perform extensive testing, including verifying that the application performs to specification across browsers and devices. When issues are detected through quality assurance, automated monitoring, or user reports, the project management team is the first line of triage, routing the request to the right party, documenting the issue, and verifying the solution.

Production Infrastructure

At the end of the discovery and design process, it is crucial to assess the expected production infrastructure requirements. These requirements can be modeled based on the technology stack, project requirements, and expected load. This assessment should be performed with the project and technical stakeholders to ensure that the technology and infrastructure achieve a sustainable long-term solution.

Mobile & Web Applications

Create human-centric digital experiences that delight users and produce business insights.

Learn More →
Fast-Growing Medical Device Company Transforms Their Customer Engagement Platform

Convertiv engineered a solution that could power customer engagement and transform a sprawling organic platform into a lean, intuitive, and performant tool.

View customer story →

A good development partner will have expertise across a wide range of infrastructure tools and providers. They will also remain agnostic to specific stacks or tools and deploy tools that are best suited to the challenge. Long-term partnerships with infrastructure and operational providers are extremely valuable. The development partner should also be willing to work with hybrid cloud solutions and on-premises infrastructure when organizational and security concerns require it.

Development Operations (DevOps)

DevOps is the hand-off between ongoing development and day-to-day operational support. For each type of project, it’s important to have a process and a set of tools to manage this hand-off in a transparent, testable, and repeatable way.

Early in development, a Continuous Integration/Continuous Deployment (CI/CD) pipeline should be implemented. This pipeline allows development to flow smoothly from development environments, through the QA process, and eventually into production. Each step should be monitored, tested, and validated with a comprehensive audit trail. Database and infrastructure changes should also be revisioned in the code, allowing any developer to quickly understand the entire project design and avoid the risk of hidden patterns.

Every release should contain logic for a non-destructive rollback in case unplanned issues arise. This allows the DevOps team to roll back the changes and review the issue with the development team. They can then revise the release to resolve the issue.


Building and managing large, mission-critical applications is complex. Even minor disruptions will have significant business impact. Instrumentation provides real-time, ongoing visibility into the application stack. When the system enters an exceptional state, administrators should be notified, and the complete event log should be delivered to developers. The specific tools and processes should be customized to the project technology and team resources.

Depending on the application needs, four levels of instrumentation may be considered:

  • Uptime Monitoring – Watch critical points for service interruption
  • Critical Exception Monitoring – Watch inside the application stack for exceptional states
  • Log Monitoring – Watch the application, services, database, and system during normal operation
  • Analytics – Watch use patterns and load to maximize performance and improve the user experience


Building and maintaining secure applications is an ongoing process. A robust set of tools, best practices, and patterns will help create and maintain secure systems. But security above all is a process. Teams should continuously build and refine their security processes, building on new learnings as the security landscape evolves.

At the start of an engagement, security experts should examine the project scope and build a security threat model. The goal is to create a clear picture of the application’s attack surfaces and the risks that will be faced. Once a risk model is in place, technical and legal stakeholders can balance competing factors around our security processes.

While all should be designed to conform to best security practices, not every application should be held to an identical level of scrutiny. For instance, applications that handle secure financial transactions must pass a PCI-DSS audit. PCI-DSS auditing and remediation are expensive and time-consuming, though they provide a significant security benefit. A public-facing, informational site wouldn’t need to be subjected to that level of scrutiny.

If extra scrutiny is deemed necessary, the team should engage proactively with internal and external auditors. The code should be subjected to both static code analysis and dynamic (penetration) testing. Applications should incorporate the latest best practices, with built-in technology designed to defeat known attack vectors. Infrastructure partners should also deploy security systems, firewalls, and monitoring to detect and respond to emerging threats. Finally, systems should be engineered with redundancy and disaster recovery plans that enable recovery after an attack. Security is an ongoing process that requires constant communication among all parties involved in the project.


Documentation is the evidence of well-written software. Inadequate documentation will increase error rates, elongate development cycles, slow response times, and ultimately shorten the application’s life, all while increasing costs.

Documentation efforts must begin at the ground floor, in the structure of the code itself. Using established, normalized, testable patterns in all systems is essential. For example, APIs should follow RESTful patterns and MVC structures. Front-end design should use techniques like Inverted Triangle for naming and structuring style definitions. Following well-established patterns makes it easy for experienced developers to jump in and contribute without acclimating themselves to a radically new system.

As the code takes shape, developers should document within the code. This includes explaining complex sections, documenting custom functions, and calling attention to project-specific deviations from the established pattern. Code repositories should have documentation in them that details how to stand up the local repository, fetch required dependencies, build the code, and deploy via the CI infrastructure.

As operational state approaches, all documentation should be centralized into a deliverable. Depending on the project, style guides, API specifications, build instructions, and code SDKs may also be necessary.

Understand and accelerate growth with us.
Get in touch