When you are the entire data function, the sequence matters more than the architecture.
The instinct when you are handed the whole data function is to build the foundation properly. Lakehouse, medallion layers, naming standards, the lot. It is the right architecture. As a first move it is close to the worst thing you can do.
Nothing is visible for weeks. The people who agreed to fund this see no change, and their confidence in it decays on a schedule of its own. Then someone asks what you have been doing, and the honest answer — building the thing that makes the later things possible — sounds exactly like the answer someone gives when they have been building nothing.
One report. One real question somebody is currently answering by hand, end to end, through whatever layers it needs, to something a person opens on a Monday morning. Not a proof of concept. The actual thing.
It is architecturally worse. It leaves you with a vertical slice rather than a foundation, and you will refactor part of it. That is the price, and it is worth paying, because the slice tells you which of your assumptions about the source data were wrong — and there are always some — while the cost of being wrong is still one report rather than one platform.
Credibility compounds. The second piece of work is easier to scope, easier to get time for, and easier to say no to badly-shaped requests around, because you have shown the first one landing. Sequencing is not a compromise on architecture. When you are the only technical person in the building, it is the architecture.
If this matched a problem you're sitting on, or contradicted your experience, that's worth an email either way.