Frequently Asked Questions

At the end of the day, you need to get clear on what matters most to you.
Here are some examples of thoughtful questions we’ve been asked:

• Who owns the software and/or work products you build?
• Do you provide teams with all the disciplines needed to build great products (i.e., UX, Engineering, DevOps, Testing, Product Management)?
• Do the teams have a history of working together before this engagement?
• How do you manage scope, schedule, and budget?
• How does staffing of my project team work? Under what conditions might people join or leave the team?
• What types of training do you provide your staff?
• What are your maker retention rates? Are they project hires?
• What kind of organizational certifications do you have (e.g. ISO, quality systems, etc.)?

We’ve always learned and incorporated the best of modern methodologies, balanced against the context of our clients. While Agile means different things to different people, we focus on practical, effective Agile practices… We deeply embrace Lean practices, putting people over process, and deliberate experimentation. Our clients often work in scaled agile approaches like SAFe, and we regularly help adapt these approaches to regulatory contexts (such as FAA or FDA).

We don’t prescribe a one-size-fits-all process because our customers are different and their needs are different. However, there are some basics you’ll see across most of our projects:

• Dual-track Agile (generally preceding development work)
• Problem and solution discovery
• Probabilistic forecasting
• 1-2 week iterations
• Typical Scrum ceremonies: sprint planning, sprint demo and review, and retrospectives
• Product increment (PI) planning
• Periodic status reporting and product demonstration, and delivery

Digging a little deeper, you’ll find these kinds of practices happening on the team:

• Test-driven development
• Pair and mob development
• User research and testing
• Continuous integration and continuous delivery
• Secure coding practices

We hire and train makers to be generalists who work in a variety of languages and platforms. Common tech we’re using these days includes JavaScript/TypeScript, .NET, Java, C++, Python, AWS, Azure, iOS, and Android. We also spend time working with IoT and various embedded platforms. You can view our Tech Details page to see all the development languages and technologies we’ve used in recent product development efforts.

Offshore development can be a good fit for certain projects, but it’s not always the best choice. Here’s when it makes sense to go offshore versus partnering with SEP: 

• The solution to build is well known (e.g., you need to build exactly the same app on a different tech).
• The problem is simple (e.g., any “coder” could do it).
• The stakes are low (e.g, you can afford to not get it right the first time).

Hire SEP when you’ve got a gnarly problem, a tight deadline, risky unknowns, a need to up your team’s game, or a great need for collaboration. When the stakes are high, you want SEP in your corner. If the cost of failure is too high to risk—think regulated environments, critical systems, or projects where ISO compliance and rigorous quality standards aren’t negotiable—we’ve been there and know how to deliver under those constraints. That said, we play well with others, including offshore and nearshore teams our clients have hired.

We staff teams to meet the specific needs of our customers’ products. Many teams start with this composition:

• Engagement Manager: Your main contact, primarily responsible for staffing, contracts, and project oversight.
• Team Lead: An experienced maker who has deep experience delivering products for customers with our teams.
• Delivery Team: A mix of designers, developers, testers, architects, and product minds who have the skills to help you understand what needs to be built and how to build it.
• The Rest of SEP: Our close-knit community of makers and practice directors at SEP means that when you hire a team from SEP, you’re getting the collective wisdom of the entire company. Our makers regularly engage with their peers on other teams for deep expertise or feedback on their own problems or solutions.

Every product needs its own unique mix of services to deliver on the intended outcome. We’re not prescriptive when it comes to user experience services. We’ll look to understand user needs and business goals in your problem space, users, and business and work to build and integrate the research and discovery throughout the product development process. As the product evolves, the entire product team and client work through phases of systems thinking and information architecture, interaction design, and user interface design practices while using exploratory and validating research methods to gain confidence that we’re solving the problem with the right solution.

We enter non-disclosures with most customers and honor those agreements (including not advertising their company logos without their permission). We work with companies of all sizes: we’re big enough to handle the toughest Fortune 100 challenge and nimble enough to join a scale-up’s market disruption. From our project portfolio page, you can see examples of the types of companies we call customers.

In 35+ years, we’ve worked in a lot of industries. In recent years, we’ve worked in Life Sciences, Precision Ag, Medical Devices, Aerospace and Defense, Home Automation / IoT, Construction, Fin Tech, and Ed Tech.

Yep! Our engineers are full-stack. While every maker has an area of focus and set of specialized skills, we don’t break down our developers into “front-end only” or “back-end only” roles.

You can expect any SEP engineer to work in any part of your stack.

Our customers put it better than we could. “You feel like an extension of our team.” “Working with SEP is an oasis of sanity.” “I never have to worry about you doing a good job.” We’ve been here before, and we’ll leave you better than we found you.

Many customers take over the long-term care and feeding of the products we build. In those cases, we work closely with those teams to make sure that the transition is effortless and drama-free.

In other situations, customers need continued outside support. We have support plans if customers don’t have the right team ready to take over the product. A Maintenance and Evolution engagement can be as simple as making sure the software is up-to-date and secure, or a hybrid model where we fix bugs and add new features.

The short answer is yes. In many cases, it’s obvious the user interface needs to be improved, but it’s typically the beginning of a much bigger conversation. Design done in a vacuum without considering cross-functional perspectives is delaying inevitable disappointment. We do research, prototype, and high-fidelity polished deliverables, but if we don’t talk about how that impacts how people use your product or the feasibility of building it, you could end up right back where you started.

When vendors do this, it doesn’t feel good. It’s a bad experience for everyone involved. You’ve invested in getting our team up to speed and familiar with your context, and don’t want to have to onboard new makers again and again.

It’s not a good experience for our makers, either. Our people like to see their work through to the end. It gives us a great sense of accomplishment to see their work actually solve the problem.

We never switch out teams or large parts of teams. On the occasion that we do need to rotate individuals (which is sometimes natural for long-running projects or due to outside circumstances), we’ll give you as much notice as possible and make the transition smooth.

If you haven’t done this before, probably more than you think.

Don’t worry. We’ll work closely with you to ballpark the work and see if it makes sense to keep talking. To put real numbers on it, our smallest projects tend to be $250K-500K, and it is not unusual for multi-year engagements to get into the $3M-$6M range.

At the end of the day, we want you to spend as little as possible to get the most return from the product we build together. To help you do that, we provide transparent forecasting and status reporting, frequently deliver working software, and help you pragmatically plan (and replan) every step of the way.

Totally. We routinely work with adjacent companies (tool/platform vendors), our clients’ teams, and teams from other companies. Our goal is to get you to a win, and we’ll do everything we can to accomplish that.

Great question! One of the worst ways that our industry lets customers down is by building a thing and hoarding all the knowledge (and sometimes the IP, too!). That’s not us! We never want you to be in a position where you HAVE to hire us because we’re the only ones who know how something works. We love to pair and to teach and onboard our customers’ design and dev teams to the work we did, so they have the confidence to take over where we left off.

The short answer is “No,” but we integrate with them all the time! Most of the time, when people ask that question, they want to know if we’re a System Integrator, as in “If I bought software (like Salesforce or an ERP), would you customize and configure it for our world?” That’s when we would say “No.” There are definitely scenarios, though, where the custom application we’re building needs to integrate with other systems. (Sometimes those are off the shelf, and sometimes they are other proprietary systems.)