How to rescue an Adobe Commerce build

In our experience, Adobe Commerce is a capable platform. The system is 100% “open source,” which means you can modify anything. This opens our conversation.

You can modify anything in Adobe Commerce. No customization extends the reach of this platform. You can change anything. Do you get the message?

This is one of the great selling points. Service providers sell this platform stating that the sky is the limit. When they get down to delivering “the sky,” they don’t do it with the methodology necessary for a significant software project. The results are catastrophic.

The scope: this article relates to new builds or migrations to the Adobe Commerce platform. However, it’s also applicable to long-term maintenance engagements. And it has widespread recognition with other ecommerce platforms.

You might face a job crisis—and it’s not your fault. Delays smash deadlines. The project costs balloon, and the website is never released. Adobe Commerce looks terrible (“Hey, try Shopify Plus, we launched on it within 30 days of a signature.”). Everyone is frustrated.

This conversation is for you if you find yourself in such a situation. Many merchants have found themselves in a similar case, if it's any comfort.

2. Take control of the situation

Focus on critical issues. Come up with a checklist of items that prevent launch. Sync with your agency on this list. Defer any item that can wait. Keep this list in front of your team and your agency (see the next topic of Establish Regular Communication).

Many builds are completed for a fixed fee. If the agency isn’t pushing change orders, their developers are likely to get burned out as they revisit the same problem repeatedly. Options for improving this project are minimal and may involve switching to a new service provider.

If this project is being billed on a time/material basis, identify whether you are more interested in a faster completion or a consistent budget. There is “X” number of hours to get this completed. A better team should be fewer hours. A less competent team is more.

You can establish monthly limits. You could also request bi-weekly budget updates.

4. Pull back the scope

Ray Bogman at Adobe has an excellent line of thinking:

If you choose to massively customize your instance, no matter what platform, you will encounter problems associated with custom code (technical debt).

A significant reason for failed projects is bloat. You, the merchant, have asked for too much to be delivered on the initial round. More often than not, features are more negotiable than you would think. Think critically about what can be immediately omitted and pushed to version 2.

There are some cases where the minimum viable project is significant. We worked with Grandstand Glass to facilitate a workflow that involved pricing complexities, artwork workflow, and approval queues. There is only so much you can cut back when you are 75% of the way through the project.

Starting right from the beginning is the best, but it’s not always possible.

5. Ensure excellent documentation

It is within your power and best interest to ensure every single ticket contains proper information.

If you can hold off until you have 2-3 reoccurrences of a problem, you will save a significant amount of budget. We have chased many 1-timers to find out they are already fixed or not a problem after all.

6. Keep a record of the problems

You’ve probably had numerous instances of playing whack-a-mole. This is frustrating as once you fix a problem, you experience a reversion.

Being familiar with the project (and fixes) is critical. Chime in with your gut feelings as to what is happening. Some people might take “offense” at a “non-developer” providing advice—but a good developer will appreciate this.

Your record doesn’t have to be a list of Jira tickets. It may be a text document detailing significant problems and their resolutions.

8. Consider a second opinion.

If you can’t get this project under control, look to get a second opinion. This should comprehensively audit the code base and UI/UX.

The audit should cover:

• Modules installed and their current version
• The quality of custom code. Does this match or exceed Magento coding standards?
• The frequency of critical code smells. Is ObjectManager in templates or code (excluding factories)? How many preferences exist in di.xml files? Is the code formatted and documented cleanly?
• The structure of the customizations.

This audit will make the unknown known. At this point, you will understand the quality of your developer output and will be able to make appropriate decisions in the future.

Note that audits increase a merchant’s alert level and they may start the process of parting ways when they find out. Take your time to investigate the agency providing the audit in case they need to finish the project.

Then, call in a rescue mission

There is a time for everything. If you have tried all of the above, it may be time to consider a new service provider.

When you do, I recommend you evaluate:

• What is their percentage of certified developers? Is it possible to find one that’s 100%? For the record, SwiftOtter maintains a 100% certified bench of developers.
• Can they assure you they have the experience to approach a new codebase and resolve problems?
• What are some of the biggest challenges they have resolved? Are any of these similar to your situation?

About us

I've seen many merchants floundering. When the website finally gets to production, it’s marred by bugs. This causes the merchant to believe the problem is Adobe Commerce—when, in reality, it’s more a management and agency problem. We have righted quite a few projects. If you’re interested in an audit or a second option, I'm happy to chat.