Lessons learnt from somehow making Compress(space) in the final 48 hours.
For LD54, I solo developed Compress(space), a puzzle game where you literally compress space to cheat your way through puzzles. The gif below shows how it works.

Originally, I was making a different game. But after ~~procrastinating~~ watching Jujutsu Kaisen, I had an epiphany about how the space compression mechanic could work in a game. I immediately threw away all of the first day's work and started working on compress(space). In the remaining 48 hours, I somehow managed to finish the game.
Here's what I learned:
Acknowledge your limitations. Cut scope as needed:
At first I wanted to no limitation on the compression ability, allowing vertical as well as horizontal folding, multiple folds etc. But the reality was that I didn't have time to code all of it. If I only allowed folding in one direction, the calculations would be much simpler. So I cut all of that extra scope and made a simpler but much more achievable game where you can only fold space left.
Embrace your restrictions:
Restrictions can also be a creative tool. The game doesn't allow you to fold space over a prop(say, laser turret).
If I allowed it, then I'd have to write extra code to handle it. It's not complicated but would likely take some time to handle the edge cases it would cause. Instead, I simply prevented the player from folding over props and designed puzzles around that. This simplified coding and provided me with another avenue for puzzle design.
Plan out how much "game" you want to/can actually make. Work based on that:
After the basic compression mechanic was implemented, I brainstormed various ways to utilize it. I then chose the ones that I could finish implementing within time and designed 12 levels on paper. I decided that 8 levels would be enough for the jam while being. So I picked 8 levels from there and coded only what was needed for those levels.
Leave some time to implement/adjust your initial plan:
When I sat down to actually implement the levels I designed on paper, I had to change and adjust them a lot. In fact, I had to redesign the entire final level several times before I could get it to work. Your initial plan will never survive reality. So be flexible.
Save some time for polish:
I had 12 hours left after I implemented the final level. After that, I didn't code any new mechanics. I just focused on polishing the game. I played around with post-processing settings, added particles etc.
Post-processing can elevate even shitty art:
The game has a really simple artstyle. It looks good only because of post-processing. The CRT effect, chromatic aberration, bloom etc. all of it was from Unity's built-in post-processing stuff. Even programmer art can be made good if you put in effort.
If your game is complicated, make proper tutorials in the game:
This is especially true for puzzle games. Very few players are going to read the huge paragraph in your description. From the very start, I had to think about how I would teach the mechanics. Even in the first 12 draft levels, I included tutorial levels. I designed a lot of small levels to gradually teach the player the mechanics. I thought I did a good job. But even then, players had trouble learning the rules. It is never enough. But you still have to try.
That's all. I hope this was useful to you. I plan on developing the game further. If you found this helpful, your feedback would help a lot.