This is a continuation of the earlier posts to enumerate funny software engineering practice:

180) Build a product that tries to be ahead of the game in emerging trends and find that a significant legacy from partners still requires older technology integration.
181) Build a product that tries to squeeze different channels into the same stream
182) Build a product that tries to distribute a stream to separate channels when the user is expecting one
183) Build a product that tries to promote a partner application from the same maker to the deteriment of competitors
184) Build a product that tries to emulate open source and invite the world to build with it duing its early stages only to find it shutting doors in its growth stage with bars for acceptance
185) Build a product that does not choose partners to foster growth and find that it cannot sustain innovation by itself
186) Build a product that gives users a tonne of information to go through when they want a summary
187) Build a product to implement a use case and leave it for solution integrators to find bugs
188) Build a product to satisfy some customers only to irk others
189) Build a product with over generalization when some customization would have served neatly
190) Build a product with ambitious charter and find the release timelines reducing the plan.
191) Build a product that does not preserve data between restarts, retries or disaster recovery
192) Build a product that does not retain user settings only to have the user apply them again
193) Build a product by putting together functionality via dependencies and find that the massive surface area attracts all kinds of vulnerabilities.
194) Build a product that creates sdks, command-line clients and other artifacts and find that the versioning for each becomes a maintenance issue.
195) Build a product that does not keep history of all actions, assets and activities only to find significant effort in rebuilding it.
196) Build a product that does not maintain registry for all users and find that there is no blacklist or whitelist capability
197) Build a product that assumes secure comunication via tunnels and find that the tunnels need not be continuous through a proxy.
198) Build a product that does not gain statistics of its usage and find that the pain grows among users
199) Build a product that has no telemetry and not have any insight into how customers are doing with the product.
200) Build a product that has built in dial home capabilities and find that privacy gurus will find it suspect.