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:

– 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.)?
– Who owns the software and/or work products you build?

We’ve always incorporated the best of modern technologies balanced against the constraints of the context. Agile is a loaded (and bloated!) term, but many of our teams will resemble a Scrum team doing typical ceremonies. We deeply embrace Lean and the Lean Startup practices, putting people over process, and deliberate experimentation. With our clients, we often work in scaled agile approaches like SAFe, and often help adapt these approaches to regulatory contexts (such as FAA or FDA). Our ISO 9001:2015 put a bow on our consistent application of best practices.

We don’t prescribe a one-size-fits-all process because our customers are different and their needs from us are different. However, there are some basics you’ll see across most of our projects:
– Probabilistic forecasting
– 1-2 week iterations
– Iteration planning, review, and retrospective
– Product increment (PI) planning and discovery
– 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
– Dual-track Agile (generally preceding development work)
– Continuous integration (and Continuous Delivery, where possible)
– 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 .NET, Java, C++, React, AWS, Azure, Xamarin, iOS, Android, Ruby, and Python. 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.

We think offshore makes sense when:

– 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.

We staff teams to meet the specific needs of our customer’s product. 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 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 needs, goals, and pains from 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 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 30+ years, we’ve worked in a lot of industries. In recent years, we’ve worked in Life Sciences, Precision Ag, Medical Devices, Aerospace, Home Automation / IoT, Construction, Medical Billing, 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 systems we build. In those cases, we work closely with those teams to make sure that 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, although long-term we encourage them to grow the capability internally. 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 sucks. 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 switch out 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 $75K-$100K, and it is not unusual for complex, multi-year engagements to get into the $2M-$5M range.

At the end of the day, you should 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.

Of course! Assuming there’s a business outcome tied to modernizing your legacy app.

Simply moving an old system into a new technology is often fraught with peril. This is known as the second-system syndrome: “Make it do the same things as the old one.” Quite often in these situations there are changes that needed to happen in addition to updating the underlying technology. These types of efforts often seem straightforward, but they rarely are.

Totally.

We routinely work with adjacent companies (tool/platform vendors), our client’s 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 should probably unpack that a little. Most of the time people ask that question, they mean “If I bought software (like Salesforce or an ERP), would you 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.)