When designing options and callbacks for middleware/helpers, favor extensible, composable patterns over narrow, single-purpose additions. - Pass the `Context` (or relevant request data) into user-supplied callbacks whenever behavior may depend on the request, so users can implement custom logic without new options (e.g. `onError: (remote, c: Context) => ...`, `generator: (c: Context) => string`, `ssgParams(async (c) => ...)`). - Accept both a plain value and a function/array where it increases flexibility, e.g. `vary?: string | string[]`, or `contentTypesAsBinary?: (contentType: string) => boolean` instead of only `string[]`. - Use a discriminated union instead of multiple independent booleans when only one option can be meaningfully active at a time, e.g. prefer `prefix?: 'host' | 'secure'` over `securePrefix?: boolean; hostPrefix?: boolean`. - Don't add a narrow convenience option if an existing generic hook/callback already covers the use case cleanly (e.g. reject `usernameContextKey` because `onAuthSuccess: (c, username) => c.set(...)` already solves it) — keep the public option surface minimal. - When a helper ships default configuration (e.g. a MIME-to-extension map), export the default so users can spread/extend it (`{ ...defaultExtensionMap, 'application/foo': 'foo' }`) instead of only allowing full replacement. - Prefer combining many related, growing parameters into a single options object with sane defaults and, if needed, an overload for backward compatibility, rather than continuously appending positional arguments (e.g. JWT `verify(token, key, options: VerifyOptions)` instead of `verify(token, key, alg, issuer, audience, ...)`). Applying these principles keeps public APIs predictable, avoids combinatorial option explosion, and gives consumers enough flexibility to handle edge cases without requiring new library changes.