KITESHADOW TECH — 鸢影技术
Some years in this line of work. Circle a little longer. See the problem clearly. Then land with precision.
About
A kite is a bird of prey. It rarely needs to flap its wings; it rides the rising air, circles high enough to see clearly, and only then descends. Its shadow crosses the ground first—people usually notice it before they look up and find the bird.
The name describes both a way of working and a belief: the thing made should be noticed before the person who made it.
Understanding the requirement, arranging the interface, designing the schema, and running the servers all come from the same set of decisions. The upside is no meetings. The downside is there is nobody else to blame.
Over the years I have built several products of my own. Some worked and were eventually sold. Others made it all the way to launch and still did not survive; I would rather not open some of those repositories even now. Most of the useful lessons came from the second kind.
Today I move only one or two things forward at a time. Nothing currently in progress is ready to share—not out of mystique, but because a few papers are still making their way through the system.
This scale has hard limits, but it offers something valuable in return: if the product needs changing a year from now, the person making the change is still the person who wrote its first line. There is no escaping the original decisions.
Principles
Before the need is clear, every technical plan is just a guess. Most rework does not come from writing the code wrong; it comes from aiming at the wrong problem. The thinking at the beginning often takes longer than the implementation. From the outside, it looks a lot like staring into space.
Data structures and contracts need to stand first; only then does the interface have something solid to carry. Building features around a mockup can look fine until the business shifts. Then patches grow on patches. With the order right, change stays change instead of repair.
Delivery is not the finish line. A product truly begins when somebody starts using it. I would rather spend longer thinking at the start than leave a place I will be afraid to touch three months later—experience says I will be the one touching it eventually.
Producing code is no longer the valuable part. The hard part is being able to explain why every piece of a system is there. “What breaks if this line disappears?” should have a direct answer, not a shrug followed by a test run.
Toolbox
Mobile work starts with Flutter. Anything that needs to sit close to the operating system drops into Swift or Kotlin instead of leaning on a plugin that almost fits. On the server, the project gets either Go or Rust—not both. Using both belongs in a résumé, not a sensible architecture.
Contact
A technical question or simply a conversation—either is welcome.
I occasionally take on one or two outside projects when the problem is worth thinking through, the schedule is humane, and the client owns the code and servers at the end. If you have an idea and want someone to build it with, that can be a conversation too—ideally after you have spent some time with the idea yourself.
Most of the time the queue is full, so a reply may take a while.