Salesforce AppExchange and Package Intern

Build or install is only answerable once the requirement is specific, so this task starts there.

Sign up for a free Developer Edition org.

Define the requirement properly.

Choose a genuine business need such as document generation, scheduling, surveys, mass email, or data quality, and write what it must do, who uses it, how often, what it must integrate with, and what success looks like.

Separate the must-haves from the nice-to-haves explicitly, since a long requirement list makes every package look inadequate.

Now research the AppExchange.

Find at least four listings claiming to meet your requirement, and for each record what it claims, its pricing model including whether a free tier exists, its review count and rating, when it was last updated, and what the reviews complain about.

Reviews describing support quality matter more than those describing features.

Assess each against your requirement.

Build a comparison table scoring each listing on your must-haves specifically, and mark where a listing's claims are too vague to score, which is itself a finding.

Then investigate the risks.

For your leading option, determine who publishes it, whether they are a Salesforce partner, what happens to your data, and what happens if the publisher disappears.

A package becoming abandoned is a real operational risk.

Estimate the alternative.

Sketch what building this yourself would involve, roughly, so the comparison has both sides.

Finally, write which two options you would shortlist and the question you would need answered before choosing.

Submit the requirement definition with priorities, the four listing assessments, the comparison table, the risk investigation, the build sketch, and the shortlist with its open question.

Listings describe the best case, and installing is the only way to know.

Choose a genuinely free package from your shortlist that installs into a Developer Edition org.

Prepare before installing.

Document your org's current state, note what the package requests access to, and write what you expect it to add.

Installing without reading the permissions requested is how orgs acquire surprises.

Install it, recording each step, every permission or access decision you were asked to make, and what you chose.

Now inventory what arrived.

Document every object, field, tab, page, permission set, and automation the package added.

Write what portion of your org's limits it consumed, since packages consume the same field and object allowances your own work needs.

Test it against your requirement.

Work through each must-have and record whether the package meets it fully, partially, or not at all, with evidence.

Then test the cases a listing would not advertise: what happens with no data, with a lot of data, and with a user on a restricted profile.

Assess the fit.

Determine how well it works with your existing objects, whether it duplicates data you already hold, and what configuration would be needed to make it genuinely useful.

Then test removal.

Uninstall it and record what was removed, what remained behind, and what data was lost.

A package you cannot cleanly remove is a long-term commitment.

Finally, write your honest verdict on claim versus reality.

Submit the pre-install documentation, installation record with permission decisions, the full inventory with limit consumption, requirement testing with evidence, the edge case tests, the fit assessment, the uninstall findings, and the verdict.

Now build the other side of the comparison so the recommendation rests on evidence rather than assumption.

Design your own solution to the same requirement, using configuration and declarative tools only.

Define the objects, fields, automation, and reporting needed, and decide deliberately which must-haves you will meet and which you will consciously skip.

Track your effort honestly.

Before building, estimate how long it will take.

Then build it, recording actual time spent per component, since the gap between estimate and actual is the most useful number in a build-or-buy decision.

Build it in your org: the data model, the automation, the user interface through layouts or a screen flow, and the reporting.

Test it against the same must-haves you tested the package against, using the same evidence standard, and record which it meets fully, partially, or not at all.

Run the same edge cases: no data, high volume, and a restricted user.

Then assess what you have.

Write what your build does better than the package, typically fitting your exact process and data, and what it does worse, typically polish, edge case handling, and features you did not think to build.

Consider the long term.

Write who maintains this when you leave, what happens when Salesforce updates, and what the ongoing cost of ownership is in attention rather than money.

Finally, record the requirement you chose not to meet and whether that was the right call.

Submit the design, the estimate against actual effort per component, the built solution with screenshots, must-have testing with evidence, edge case results, the honest comparison, the maintenance assessment, and the skipped requirement note.

This is the deliverable: a clear recommendation supported by what you actually found.

Compare on evidence.

Build a side-by-side comparison of the package and your build covering requirement coverage, effort already spent, ongoing cost, flexibility, maintenance burden, and risk.

Use the real numbers from your own work rather than estimates.

Calculate total cost of ownership over three years for each option.

Include licence cost, build effort, maintenance time, the cost of training people, and the cost of migrating away later.

State every assumption, since a TCO without assumptions is just a number.

Assess the exit.

For each option, write what leaving it involves: for the package, what happens to data on uninstall; for your build, who maintains it if you go.

Lock-in is a cost even when nobody prices it.

Consider the organisation, not just the solution.

State which option suits a business with no technical staff and which suits one with an administrator, since the right answer differs by capacity.

Now write the recommendation of roughly 700 words for the business owner.

State plainly which option you recommend, the two or three reasons that decided it, what the business gives up by choosing it, and the conditions under which you would recommend the other instead.

Avoid platform jargon.

Add the decision rule.

Write the general guidance you would give for future build-or-buy decisions, based on what this exercise taught you.

Finally, state what you got wrong in your initial expectation and what changed your mind.

Submit the evidence comparison, the three year TCO with assumptions, the exit assessment, the organisational fit analysis, the recommendation, the decision rule, and the changed-mind note.