It’s a good question. Lack of confidence in a dev team can be caused by any number of factors, including:

1. The dev team is, in fact, weak.
2. The team’s technical skills are solid, but they’re undermined by poor communication, especially around requirements and expectations.
3. Past failures, e.g., missed deadlines, bugs, or downtime make it impossible to reestablish trust. This can be true even if those failures had nothing to do with the current team.

But how do you know which? If you’re grappling with this issue, identifying the specific cause can be difficult, especially if you don’t have a software background. (This is where a technical review can be useful!) Don’t worry – we can help. In this post, we’ll show you how to identify common signs that a dev team isn’t performing as expected, even if you’re not that technical.

Before we review the symptoms, though, please bear this in mind: If your team shows these signs, it doesn’t necessarily mean they’re weak. It means that you – or someone you trust – need to dive in to figure out what’s going on.

The Founder-Developer Gap and A, B, C Players

The challenges that business leaders face when assessing development teams are a good example of the Founder-Developer Gap. The fact is, developers operate in a world that outsiders can’t easily understand. It’s hard to know if a developer is an A, B or C player, or a player at all. And in the software world, an A player is worth 10+ C players!

Unfortunately, there are a lot of C players out there. When we interview potential developers, we’re always amazed at how many can’t answer basic programming questions. It makes us wonder, how did these folks graduate from their CS program or their bootcamp? And how did they build their impressive resume? (Maybe with ChatGPT!)

The Symptoms

Here are the red flags we hear about most often. These are the worries that keep team leads up at night. Knowing how to spot these signs can help you keep your business on track.

1. Missed deadlines.
2. Last minute scope-cutting to avoid missing deadlines.
3. Delivery of code that has clearly not been tested.
4. Marking bugs as fixed that aren’t fixed.
5. Racking up massive overtime.
6. Lack of communication between developers.
7. Dev teams without a clear leader.
8. Rogue developers with their own agenda.
9. Private bits of code that are jealously protected by a single dev.
10. Shifting blame and finger pointing.
11. Fixing one bug breaks something else.
12. Developers seem unconcerned about bugs or system downtime.
13. Developers become annoyed at testers for finding bugs.
14. The same bugs/problems occur over and over again, and no one wants to find the source of the problem.
15. New features always require significant rewrites, and consequently a lot of time.
16. Developers can’t explain why changes will require more or less development time.
17. During team meetings, developers are quiet when bugs, features, changes are being discussed, only to come back with questions later.
18. Rapid turnover, especially of senior or “A” developers.
19. Developers aren’t aware of the progress of the current dev cycle, or even what’s in it.

And the #1 symptom relates to that old software engineering adage:

From a CEO’s perspective, this translates into:

If you’re seeing some of these symptoms, you may have a weak development team. But to repeat our previous warning, you might not! There may well be other problems keeping your team from being effective. To find the answer, you’ll need a deep-dive analysis. But it’s best to start with a phone call for a quick reality check – and we are happy to do that with you.

What Makes a Team Strong?

It’s useful to approach this problem from the opposite direction. What are some characteristics of a strong team?

A strong development team should have the following:

• A high service level and availability of their product/system.
• A high throughput of effective change.
• A low amount of unplanned work.
• A culture of change management.
• A culture of continual improvement.
• And a culture of root-cause analysis.

If your team shows these characteristics, then make sure they know they’re appreciated! And don’t be surprised if you see some weaknesses and some strengths. That’s to be expected.

Recovery is Extremely Hard

Software development is challenging. Asking the right questions during requirements gathering – which is essential – doesn’t come naturally to most devs. Edge cases are easy to miss, even for experienced programmers. Aggressive timelines and pressure from management create plenty of opportunities to introduce bugs.

Early failures by a development team can make it difficult – next to impossible, really – to recover trust. If your co-workers or your manager think you’re doing a bad job, it’s very hard to overcome that perception.

Bottom line: If you have concerns about your development team, read the list of symptoms carefully. If you find yourself nodding your head in agreement, you might have a weak team.  And it never hurts to get an outside opinion!

Most innovators don’t have a technical background, so it’s hard to evaluate the truth of the situation. We hear them explain that their current software development is expensive, deliveries are rarely on time, and random bugs appear. The explanation from software leadership is often unsatisfying or unclear. And unless they have a tech background, they can’t look under the hood themselves.

What does a business leader do in this situation? The reality is that it’s not a hard problem to address. The answer is to engage a trusted outside source for a Technical Review – a deep-dive assessment that provides a C-suite perspective. At TechEmpower, we’ve conducted more than 50 technical reviews for companies of all sizes, industries, and technical stacks.

Technical Review Defined

A technical review is a deep-dive assessment of your software, infrastructure, team and processes. It provides findings and recommendations intended to foster a mutual understanding between business and software leaders, shedding light on the current state of your technology and your team. It also provides concrete recommendations for improvements.

Common Signs You Need a Technical Review

We’ve already mentioned the most common signs that you might need a technical review:

• Slow or late delivery: “I’ve authorized two new developers, and we’re still behind.”
• Random or persistent bugs: “The menu bar has been fixed three times now!”
• Sleepless nights from strategic worries: “Am I building the right tech, the right way?”

But everyone’s situation is unique. Your reasons for needing a technical review will depend on your business goals. Think ahead to tomorrow, to the next six months, and to next year. Are you preparing to expand, take your business in a new direction, or take on new partners? Even if you’re happy with your tech team, a review can ensure your business is in a good place before you take your next big step.

Other common scenarios that we’ve seen:

• Scaling and new markets: Your company and product are established, and now you’re scaling or going after new markets. These are classic inflection points for a development  team. It’s important to ensure that they’re on a strong footing as significant changes occur. Otherwise, the downstream technical debt created can be overwhelming.
• Keeping up with the competition: You’re a market leader in a fast-growing field. Newer, nimbler competitors keep introducing new features before your team can catch up. A technical review can help your development team adopt new processes and strategies to maximize their speed and efficiency.
• Outgrowing your stack: Your tech stack was just right for your startup. But as you’ve grown, it’s become cumbersome and constraining. Your tech team is suggesting a costly, time-consuming overhaul. But is that the right strategy for your business? A technical review can answer that crucial question.
• Changes to the tech team: You need to make changes to your tech team to meet your business goals. But what does the right team look like? A technical review can help you decide what team will work best both with you and for you.
• Due diligence prep: You’re coming up on a funding round or looking at a potential exit. Your investors and buyers will be doing a technical review. Are you ready? Do your own review first so you can be confident and better positioned.

There are almost as many reasons to do a technical review as there are software-enabled businesses. If you’re a CEO, product leader, investor, or a founder looking for investors, a technical review conducted by a neutral, experienced third party will help you discover what’s really happening and what’s needed to make improvements.

How it Works – The Review that’s Right For You

We know what a review can do for you. But only you know what you really need. That’s why it’s important to discuss your specific situation early in the process, ideally before the review even begins. This allows us to shape our approach to your unique needs. Then, at the start of the review, we speak with other key stakeholders to understand where they’re at and what they need.

So, how your review might work depends a lot on your situation – there’s your standard tech person caveat! 🙂  But at a minimum, any good review should include:

• Straightforward Analysis: A straightforward report that grades aspects of your technology, processes, and team. It’s written for a business leader, not an engineer.
• Pragmatic Assessment: An in-depth evaluation by working engineers who understand what it takes to deliver in different development situations. This part of the report can go deep on how your software stacks up with respect to feature delivery, security, reliability, and scalability.
• Expert Recommendations: Concrete next steps that working engineers believe would be appropriate to consider.
• Findings Sessions: A review meeting to decode findings, gauge their business implications, and chalk out a roadmap for the future.

Let’s look at the process in more detail. Here’s what a typical review looks like, step by step.

Background Information Review

Our first step is to review existing background materials. Our goal is to build a decent understanding of your business, your product, and your technology.

This might include business-side materials like your product roadmap, business plans, and competitor analysis, as well as technical materials like requirements documentation, screen comps, and project/process systems like Jira and Confluence.

Discuss Pain Points

To borrow the famous quote, all successful software projects are alike; every struggling software project struggles in its own way. To help you, we need to understand your specific concerns.  What’s keeping you up at night? Understanding your pain points shows us where to focus our review. We keep these pain points at top of mind throughout the review.

Questions and Conversations

We provide the tech and product teams with a list of questions that cover a wide variety of topics including software architecture, hardware/software technologies in use/planned, hosting, external services and dependencies, deployment strategy, development process and tools, testing approach, data science, security, and other relevant topics.

We then review the answers with the technical and product teams.

An interesting side note: During our Q and As with dev teams, we often end up having conversations around issues that they haven’t even thought about. It’s not because they’re inexperienced or incapable – it’s because they’ve been so focussed on shipping features that there hasn’t been time for anything else. This is exactly the sort of thing that a technical review can help address.

Here are some questions that can trigger those kinds of conversations:

• What areas of the applications are the most difficult to work on? And what causes that?
• What amount of time is spent on bug fixes and maintenance versus development of new features?
• How would your product perform if your user base were to scale up by a factor of 10? By a factor of 100?
• How are you monitoring your systems and applications?  Who responds to alerts?

Architecture Review

We meet with your tech team to review the overall architecture of your systems and applications. Our goal is to get a big-picture understanding of your systems, including how complex they are. We also begin to assess how well the architecture fits with your business needs.

Targeted Code Review

In this step, our senior engineers review the source code that drives your business. Does the code follow best practices? Are there repeated bugs or security holes? Our goal is to make sure your team’s code is appropriate for the situation.

Why a targeted review? It’s not practical, or even worthwhile, to examine every line of code. We provide value by targeting our review towards key components across your application stack.

Process and Team Review

It’s easy for development teams, especially startup teams, to cut process corners in the name of shipping features. However, short-cuts on process can lead to problems downstream. It can also lead to a software team that looks ill-equipped.

To head these off, we start by reviewing your team’s overall methodologies, and then drill down to details like source control workflow, ticket management, and code review processes. This step helps us identify why development priorities get stuck or abandoned, determine if the right people are working on the right tasks, and identify development hurdles and roadblocks.

This step can include a review of each team member’s contributions, down to individual commits. If you’re concerned that some of your developers are not allocated wisely, a contribution review can help.

We also assess the makeup of your dev team. We check out the team’s makeup, skill sets, and past work to ensure they align with what your business needs.

Findings and recommendations

This is what you’ve been waiting for! We provide you with a report, written for a business audience, that includes:

• Executive Summary: We grade your architecture, source code, process, and teams, and provide a brief rationale for each grade.
• Detailed Findings: For each of the areas in the executive summary, we provide the details. Honestly, this often doesn’t get more than a skim from business leaders, but certainly gets a thorough read from the technical team.
• Recommendations: Specific recommendations based on your pain points, the findings and what we believe are pragmatic choices for your business.

Review Meeting

Once the business and technical teams have had a chance to review the findings report, we conduct a meeting, or series of meetings, to discuss the results and next steps.

Getting Buy-in from Leadership

Business leaders are often concerned about how their tech teams will react to an external technical review. Will they resent scrutiny from the outside? Will they refuse to cooperate or push back?

While this can be a challenging conversation, it’s not as hard to get technical leaders on-board as you might think. Let’s assume that you’ve already expressed your frustrations with technical leadership. In our experience, the tech teams generally welcome the review. They’re often frustrated by the same problems that trouble the business team – or different problems that the business team doesn’t even know about, but should. They are happy to share their concerns with us, and generally agree with our conclusions. After all, they want you to succeed too!

It’s important to get buy-in from product leadership as well, so we make sure they are also involved in the process. That said, we find that most of the time they are expressing the same concerns as business leaders and getting their buy-in is much easier.

All of that said, we highly recommend discussing your specific situation with us prior to getting too far into the conversation. It’s easier to secure buy-in if we know where everyone stands.

Why TechEmpower?

Choosing the right partner for a technical review is important. You need a team who’s well-versed in technology and capable of translating that know-how into pragmatic options. It’s also important that they have experience in technical evaluations and in building real-world systems. We can’t emphasize that last part enough! If you bring in a consultant who spends all their time doing technical reviews and hasn’t built a system since the dot-com boom, you’re probably wasting your time.

At TechEmpower, we’ve done over 50 technical reviews for budding startups, scaling enterprises, discerning investors, and ambitious companies seeking investment or acquisition.  Our professionals bring expertise, neutrality, and depth to the process, and we approach each review with a unique blend of technological prowess and leadership acumen.

Bottom line, if you’re a CEO or founder, ask yourself these questions: Am I getting my money’s worth from my development team?  Do I really know what’s going on under the hood?  If the answer isn’t an unqualified yes, then email us to discuss a technical review.

The answer is: it depends.

The role of a CTO varies as the company matures. Here’s a graphic from Socal CTO that illustrates the roles as they change over time:

In its earliest days, a startup’s top need is often to produce a product. Getting something to market and getting funding override any other concerns. That’s why the CTO’s attention is on programming for the earliest stage.  

But be careful, and mind the gap – the Founder-Developer Gap, that is! Hiring a hands-on lead developer might seem like the right move for an early stage startup. It’s understandable – a hands-on developer can produce a product. But hiring a lead developer, or even a VP of Engineering, can create a gap between the founders and the developers.  

Founder-Developer Gap

How big is your startup’s Founder-Developer Gap? Is it a tiny crack, or a widening chasm? And how can you tell?

One sign of a gap is questions – really, a lack of questions – coming from your developers. Check out our blog post 53 Questions Developers Should Ask Innovators. If you’re not hearing those questions from your developers, you’ve got the gap.

Often, developers don’t think to answer these questions. Instead, given a startup project, they’ll default to building everything in-house, using technologies that they’re already familiar with. This is a safe choice, of course – but is it the best choice? Is it the best path to profitability?

It might be. But you shouldn’t rely on the defaults. A CTO can help you find the right answers.

Closing the Gap: Hiring A Fractional Startup CTO

We’re not suggesting that early-stage startups should hire a full-time CTO. Instead, they should consider a Fractional CTO who can help close the gap. This is especially true when a founder has a strong vision but limited knowledge of the technology needed to make it a reality.

Bottom line – if you recognize this gap, then reach out to get a slice of a CTO who can help bridge the gap.

Can the Right Lead Developer Address This?

Theoretically, an outstanding lead developer can provide good answers to all these questions.  But our experience suggests it doesn’t usually work out that way. And even if you prompt a good lead developer to answer, you’ll likely still have a gap. This is because the lead developer will often be:

• Limited by their experience and breadth of knowledge
• More interested in diving in to build things
• Challenged to pull together a good team
• Motivated by the short-term because that’s the focus of development
• Tired at the end of a long day of programming and not interested in thinking longer term
• Uninterested in or unable to add much value to investor presentations, business proposals, and new business meetings

Again, it can be done. It’s just not a realistic expectation. You don’t want to be in the meeting when the investor asks why you didn’t use their favorite new technology – at least, not without a good answer! And you certainly don’t want to be the company that spends time and money building something you could have picked up off the shelf.

More on the Role of the Startup CTO

Eric Ries, a great resource, answers the question What Does a Startup CTO actually do?

• Platform selection and technical design
• Seeing the big picture (in graphic detail)
• Provide options
• Find the 80/20
• Grow technical leaders
• Own the development methodology

And here are some links that are less Startup CTO, and CTO more generally:

• Top Ten Goals CTOs Should Focus On in 2023
• 14 Essential Tech Blogs Every CTO Should Follow
• SoCal CTO
• What You Need to Know before You Start as CTO
• Mark Suster – Want to Know the Difference Between a CTO and a VP Engineering?
• Aspatore Inside the Minds Series, Leading CTOs
• Mark Minevich, The CTO Handbook
• Tom Berray and Raj Sampath,the Role of the CTO: Four Models for Success
• Werner Vogels – The Different CTO Roles
• Role of the CTO

If you know of more resources on this topic, we’d love to hear from you. Please write us at blog@techempower.com !

• Customer Acquisition Cost  (CAC)

How will your business reach prospects? How will you convert them? And how much will it cost to win them?

• Customer Lifetime Value (CLV)

How much money will your business generate from each converted customer?

These two questions/answers can help define the early proof points for your company. If you can demonstrate that your CAC and CLV numbers work as expected, then you’ve proven you can make money.  

Proving your Business Model Works – Build, Define, and Review

But how do you prove your numbers?  

Start by building just enough of your product to get early CAC and CLV signals (they won’t be perfect). Don’t worry about scaling just yet. If your numbers work out, then scaling becomes a question of capital. 

Next, define what you need from a metrics and reporting standpoint. Look at different customer acquisition channels, how they are converting, and the expected lifetime value of customers acquired through those channels. Apply costs to each channel. We need to make sure we have these numbers. Quite often the goal is to get them into a spreadsheet in a form that allows people to easily play with them.

Finally, review the numbers with your partners. Don’t overcomplicate things with reporting tools.  Just get your numbers into a Google sheet so you can work with them easily.

Startup Metrics with Dave McClure

Dave McClure has a great presentation on Startup Metrics where he points to some additional metrics that are useful to consider:

• A: Acquisition – Where / what channels do users come from?
• A: Activation – What % have a “happy” initial experience?
• R: Retention – Do they come back & re-visit over time?
• R: Referral – Do they like it enough to tell their friends?
• R: Revenue – Can you monetize any of this behavior?

The metrics, and how they relate, are captured in his slide:

Note the relationship between retention/referral efforts and lifetime value. This isn’t a simple, first-cut acquisition pipeline! Dave’s model provides a much richer understanding of what’s happening, but in a way that’s understandable and measurable.

Another thing that Dave has done well is to look at the value of different marketing channels:

There’s a lot of value in this presentation. Some key slides to check out:

The Startup Metrics Religion

• The Progress is not equal to features (Less is More)
• Focus on User Experience
• Measure Conversion; Compare 2+ Options
• Fast, Frequent Iteration + Feedback Loop
• Keep it Simple and Actionable

What’s my business model?

• Get Users (= Acquisition, Referral)
• Drive Usage (= Activation, Retention)
• Make Money (= Monetize)

Startup Challenges

• Management: Setting priorities, defining key metrics, reporting progress
• Product: Build the right features, getting product out quickly, testing for conversion/adoption
• Marketing: Accessing “web 2.0” channels (search, social, viral, new media), cost-efficient distribution

We often reference Dave’s work when talking to innovators. Be sure to check out the entire presentation.

Conclusion

Startup metrics are an invaluable tool for founders and innovators. Focus on building an MVP to gather startup metrics. Then use what you’ve learned in this blog post to decide if the numbers validate your business model, or if you need to rethink your approach.

If you know of more resources on this topic, or want to talk about anything startup or tech related, we’d love to hear from you. Please write us at blog@techempower.com !

The conversations are interesting and varied because they’re about new, exciting, different things. After all, that’s what tech innovation is all about. But there are some common elements too. One common element – and one that’s pretty surprising – is that often, no one has asked these innovators even the most basic technical questions.

Even when they have talked to multiple developers or development firms, we’re often the first to ask basic questions like “Who are your customers?” or “Are you developing for desktop, tablet, mobile, or all three?”

Of course, it’s more complicated than just checking boxes on a question list. The innovator/developer relationship needs to be a conversation. Still, if you’re a business leader and your developers haven’t asked you these questions, look for a Fractional CTO to help navigate the critical early stage of development.

Background Questions

Let’s start with some background questions about the business and product. Think of these as the big upfront questions a developer should ask to get an overall picture.

1. Who are the customers? What’s their specific need/pain? Can you provide specific examples of different types of customers, what they need, and what the system will do for them?
2. Tell me about the business. How are you funding this? What level of funding do you currently have? Who’s helping you with fundraising? Do you have legal (Founder Agreement, IP, etc.) in place?
3. What are your big milestones? Do you have any deals done or in progress that are tied to those milestones? Where are you today, and what’s happening right now?
4. What’s been done so far to validate the concept?
5. Who are the other stakeholders involved? Are there other founders, business leaders, partners, or administrators?
6. How will you be taking this to market? What channels will you use (e.g., Ads, Viral/Social, SEO)? Is anyone working with you on this?
7. What are your key Startup Metrics? How do you make your money? How do you measure success?
8. Who are your big competitors? What are some sites or companies in the same space? How will you differentiate from these?
9. What is different, special here? Where’s the mystery? Do you have a custom algorithm or other technology?
10. What special data, content, APIs, etc., will you leverage? What’s the state of the relationships that brings you that data? What’s the state of those systems?
11. Where do you stand on your brand? Do you have a name, a logo, and have you thought about brand positioning? What are some examples of similar brands?
12. Are there any specific hard dates or important time-sensitive opportunities?
13. What do you see as your biggest risks and challenges?
14. What are the key features in each major phase of your application? What functionality would make your company launch-ready?
15. What has been captured so far? Are there user stories? Mock-ups? Wireframes? Comps?
16. What problem is your product trying to solve?
17. If you launched tomorrow, how many users would you forecast? Six months from now? A year from now? How quickly will we need to scale the application?

Questions Developers May Have Forgot to Ask

Here are some additional questions that might have slipped your developers’ minds.

1. eCommerce

Does your startup run on a subscription model? How many kinds of subscriptions do you support? What are the rules for subscriptions? Do you support discounts? Free trials? Bundling? Coupons?

Often this ties to marketing support. For example, you might want to offer a discount to a given group to provide incentive.

2. Targets

Are you developing a native app and/or a web app? Are you targeting desktop, tablet, or mobile? Can you do a hybrid web/native application? Which devices will you test on specifically? Most new sites need to account for mobile delivery – but on the other hand, not every MVP needs both desktop and mobile versions.

3. Registration

Do you plan to support Google Sign-In, Facebook Connect, or similar 3rd-party authentication? If so, will you also have your own account system? Will you validate new members’ email addresses and/or phone numbers?

4. Artificial Intelligence

Does your application leverage AI in any way?  For customer service?  To personalize customer recommendations? How can we use AI to improve the customer experience?

5. Member Profiles

What data is included? Is there a step-by-step wizard? Can members upload their pictures? How much member profile information do you need before allowing a user to register?

6. Social Integration/Viral Outreach

Is your application tied into any social networks? How tight is that integration? Is it limited to login and Like buttons, or are you building a presence within the social networks themselves? What about other kinds of viral outreach?

7. Communication/Forums

Are there discussion forums? Commenting? Messaging? If you have boards or comments, do you support flagging? Moderation?

8. Social Interaction

Do users/members relate to one another? If so, how do they interact? Are users otherwise grouped by the system, maybe by background (employer, university) or preferences?

9. Internationalization/Localization

Do you anticipate an international audience? How important is support for multiple languages? For multiple character sets? How do we prioritize internationalization versus getting something to market?

10. Location/Geography

Is your application location-aware? Does it tap into geolocation services provided by the browser or rely on a third-party lookup table? How are you using geographic information? How does the application behave when location data is not available?

11. Gamification/Scoring

Does your application include any kind of scoring and/or gamification? Are there achievements and badges? Is there a leaderboard for users or teams?

12. Video and Audio

Are you hosting your own video, or can we use a third-party host like YouTube or Vimeo? Do you need to process user-contributed media? What about reporting and moderation?

13. Notifications

What notifications does your application need? Are they dismissable? Do they generate emails or push notifications?

14. Email / SMS

Does your application send out transactional emails or SMS messages? In mass? How are those mass messages crafted? How often is message content updated? Do you need to track views and bounces? What are your privacy rules?

15. AI Assisted Development

How can we use AI to speed up our SLDC?  How can we leverage AI to get our product to market faster?

16. Marketing Support

What does your application need to do to help with marketing? Do you have specific landing pages? What are your referral sources, and what tracking do you need around these sources? Do you rely on affiliates? Is there a need for A/B testing?

17. SEO Support

Will URLs and page content need to be properly formed for SEO? What back-end support for SEO is needed?

18. Content Management

How often will the application’s content need to change? Who will be doing the changes?  Will you need to add arbitrary new pages? Should content changes be scheduled? Are members contributing content or only system administrators?

19. Dates and Time Zones

Does the application need to support multiple time zones? Does it need to convert dates automatically?

20. Search

Does the application include search? What content is searchable? How advanced does it need to be?

21. Logging/Auditing

What key operations need to be logged for auditing? What needs to be logged for customer support?

22. Analytics/Metrics

What key startup metrics will you need to track? What metrics will you need for future funding rounds or operations?

23. Administration

What will you need to do from a back-end? Administer users? Send messages?

24. Reporting

What needs to be reported? Are CSV/Excel exports sufficient, or do you need something more? Reporting can be endless! Our advice: keep it small to start.

25. Accounting

Beyond reviewing transactions, what accounting support do you need? Do you need to track inventory? Fulfillment?

26. Customer Support

Do you need specific interfaces and support for customer service? Do you need a ticket system? What about an AI support assistant?

27. Security

What are the business / application’s specific security risks? Does it need to throttle potential malicious activity? This generally is a significant discussion itself! Our advice: be pragmatic!

28. Performance 

What is the expected request volume? What response time characteristics are required? How complex is the application? Complexity can directly impact performance.

29. Integration Points

What third-party systems will we need to integrate with? How far along are any integration efforts? What is the business relationship with the third parties? Who controls access to the third-party accounts, if any?

30. Existing Capabilities

What capabilities and personnel do you already have access to? Graphic design? UI/UX design? A Product Manager? How much availability do they have to work on this effort?

31. Hosting

What hosting requirements does your application have? Do you have any existing hosting relationships?

32. Platform

Are there pre-existing technical platform decisions that must be considered?

33. Team and Process

Are you using, or planning to use any software development methodologies? How big is the anticipated development team? How will it be structured?

34. Product Management

Do you have a clear vision of the initial application and a plan for sequencing changes after the initial launch? Do you have the internal staff to manage changes?

35. Compliance

What regulatory compliance do you need to support? GDPR? CCPA? HIPPA?

36. Expansion

What is your vision for the expansion of the application? What features should be in place at launch? Six months from now? A year from now?